Python Programming: Page 3

From gotos to the evolution of life in 10 posts; that's comp.lang.python for you!

A.M. Kuchling, 4 Apr 1998

This is Python! If we didn't care what code looked like, most of us would probably be hacking in some version of Lisp -- which already covered most of Python's abstract semantics way back when Guido was just a wee snakelet frolicking in the lush Amsterdam jungle.

Tim Peters, 24 Apr 1998

The infinities aren't contagious except in that they often appear that way due to their large size.

Tim Peters on the IEEE 754 floating point standard, 27 Apr 1998

The "of course, while I have no problem with this at all, it's surely too much for a lesser being" flavor of argument always rings hollow to me. Are you personally confused by the meanings for "+" that exist today? Objecting to the variations is a different story; I'm wondering whether you personally stumble over them in practice. I don't; Steven doesn't; I doubt that you do either. I'm betting that almost nobody ever does, in which case those "less nimble colleagues and students" must be supernaturally feeble to merit such concern.

Tim Peters, 29 Apr 1998

"Ideally, IMO, two messages with the same name should have the same meaning but possibly different implementations. Of course, "meaning" is somewhat relative, but the notion that two messages with the same name should have the same 'meaning' is very useful."

"Like clothes.launder() vs money.launder(), or shape.draw() vs blood.draw(), or matrix.norm() vs hi.norm() <wink>? I'm afraid English thrives on puns, and the same word routinely means radically different things across application areas. Therefore, to insist that a word have "one true meaning" in a programming language is insisting that the language cater to one true application domain."

Jim Fulton and Tim Peters, in a discussion of rich comparisons, 29 Apr 1998

Indeed, when I design my killer language, the identifiers "foo" and "bar" will be reserved words, never used, and not even mentioned in the reference manual. Any program using one will simply dump core without comment. Multitudes will rejoice.

Tim Peters, 29 Apr 1998

Too little freedom makes life confusingly clumsy; too much, clumsily confusing. Luckily, the tension between freedom and restraint eventually gets severed by Guido's Razor.

Tim Peters, 29 Apr 1998

In other words, I'm willing to see dark corners added to the language, as long as I don't have to go into them myself.

A.M. Kuchling, 29 Apr 1998

This argument is specious. What on earth would it mean to compare an object you created with another object from someone else's code unless you knew exactly what each object's semantics were? Do you really want to ask if my abstract syntax tree is less then your HTTP connection object?

Jeremy Hylton, in a discussion of rich comparisons, 29 Apr 1998

Two things I learned for sure during a particularly intense acid trip in my own lost youth: (1) everything is a trivial special case of something else; and, (2) death is a bunch of blue spheres.

Tim Peters, 1 May 1998

Well, they will be: "<" will mean what everyone thinks it means when applied to builtin types, and will mean whatever __lt__ makes it mean otherwise, except when __lt__ isn't defined but __cmp__ is in which case it will mean whatever __cmp__ makes it mean, except when neither __lt__ or __cmp__ are defined in which case it's still unsettled. I think. Or isn't that what you meant by "clearly defined"?

Tim Peters, 6 May 1998

You write a great program, regardless of language, by redoing it over & over & over & over, until your fingers bleed and your soul is drained. But if you tell newbies that, they might decide to go off and do something sensible, like bomb defusing<wink>.

Tim Peters, 5 Jun 1998

OO styles help in part because they make it easier to redo large parts over, or, when the moon is shining just right, to steal large parts from someone else. Python helps in many additional ways regardless of style, not least of which in that it hurts less to throw away 50 lines of code than 5,000 <0.5 wink>. The pains, and joys, of programming are qualitatively the same under Python. There's less pain less often, and joy comes quicker. And that's worth a whole lot.

Tim Peters, 5 Jun 1998

I've had a DBA tell me that what I wanted to do "could not" be done because his silly $5000 tool couldn't model it. Proving him wrong simply increased his conviction that what I was doing was immoral and perverse. Which, come to think of it, it probably was. Hee hee.

Gordon McMillan, 8 Jun 1998

The majority of programmers aren't really looking for flexibility. Most languages that enjoy huge success seem to do so not because they're flexible, but because they do one particular thing extremely well. Like Fortran for fast number-crunching in its day, or Perl for regexps, or C++ for compatibility with C, or C for ... well, C's the exception that proves the rule.

Tim Peters, 11 Jun 1998

It has also been referred to as the "Don Beaudry hack," but that's a misnomer. There's nothing hackish about it -- in fact, it is rather elegant and deep, even though there's something dark to it.

Guido van Rossum, Metaclass Programming in Python 1.5

Just point your web browser at and look for "program", "doesn't", "work", or "my". Whenever you find someone else whose program didn't work, don't do what they did. Repeat as needed.

Tim Peters, on python-help, 16 Jun 1998

Now some people see unchecked raw power and flee from perceived danger, while others rush toward perceived opportunity. That's up to them. But I think it's enormously clarifying in either case to see just how raw this particular gimmick can get.

Tim Peters, 16 Jun 1998

Every language has its partisans, usually among folks deeply immersed in their particular theology, triumphant in having divined the inner meaning of some esoteric operations, like a medieval Jesuit hot on the trail of the final ontological proof, whose conciseness in solving a single problem makes them almost swoon with ecstacy at the expected savings of many keystrokes, as if those very keystrokes represented a lot of heavy lifting and hauling on their part.

John Holmgren, 18 Jun 1998

> In general, the situation sucks.

mind-if-i-use-that-as-my-epitaph<wink>?-ly y'rs - tim

Timothy J. Grant and Tim Peters, 22 Jun 1998

> Just for the record, on AIX, the following C program:

Oh no you don't! I followed AIX threads for the first year it came out, but eventually decided there was no future in investing time in baffling discussions that usually ended with "oh, never mind -- turns out it's a bug" <0.9 wink>.

Vladimir Marangozov and Tim Peters, 23 Jun 1998

Python - why settle for snake oil when you can have the whole snake?

Mark Jackson, 26 Jun 1998

The problem I have with "SETL sets" in Python is the same I have with every other language's "killer core" in Python: SETL is much more than just "a set type", Eiffel is much more than just fancy pre- and post- conditions, Perl's approach to regexps is much more than just its isolated regexp syntax, Scheme is much more than just first-class functions & lexical closures, and so on. Good languages aren't random collections of interchangeable features: they have a philosophy and internal coherence that's never profitably confused with their surface features.

Tim Peters, 10 Jul 1998

"Since I'm so close to the pickle module, I just look at the pickles directly, as I'm pretty good at reading pickles."

"As you all can imagine, this trick goes over really well at parties."

Jim Fulton and Paul Everitt on the Bobo list, 17 Jul 1998

My theory is that the churning of old threads and reminiscences (Continuations, Icon influences, old-T-shirts, the pre news-group mailing list archive, whitespace, closures, .... ) has brought some old messages to the surface, via some mechanism similar to the way plankton and other nutrients are cycled in the ocean.

Steven D. Majewski, 23 Jul 1998

In general, Our Guido flees from schemes that merely change which foot gets blown off <0.45 caliber wink>. Schemes that remove the firing pin entirely have a much better, um, shot <wink>.

Tim Peters, 25 Jul 1998