[Python-Dev] Release Schedules (was Stability & change) (original) (raw)

Alex Martelli aleax@aleax.it
Tue, 9 Apr 2002 08:16:57 +0200

On Tuesday 09 April 2002 07:32, Raymond Hettinger wrote: ...

Before deciding on an overly conservative response, consider whether the real issues are behind us.

The intensity of the reaction to PEP 285 doesn't suggest that, in terms of perception. Yes, I see your last paragraph explaining that, but I only agree with it partways.

The anti-change cult may have drawn the line at augmented assignment and are prepared to rage for an eternity at print >>,

I'm not a member of any anti-change cult -- aug.ass. is good, list comprehensions great, etc, etc -- but I'm quite prepared to "rage for an eternity at print>>". You seem to be lumping people together too much. Cannot one examine each change on its merits and like or love many but still detest print>> ...?

welcome a refactored parser, an exposed parser, unified ints/longs, and optimized variable access.

FWIW, I was originally slightly wary of int/long unification, but having tried it out to the extent in which it's in 2.2 I like it now. I don't remember why I had been left with that wariness from (I think) Scheme experiences -- maybe too-slow machines back then, or careless arithmetic on my part at the time.

bugs, expanding the library, filling in missing features, optimizing, and instrumenting aren't the issue. Just don't mess with the syntax and people won't freak.

So how do you explain the intensity of the reaction to Booleans? No doubt one could class them as "filling in missing features" -- whether that's "filling a badly needed gap", in Thomson's words, I won't take up again:-) -- but the reaction might uncharitably be described as "people freaking". Messing with the semantics may thus provoke intense reaction too.

I think the 6-monthly rate of "stable" releases does have to do with it. If Booleans had been introduced into a declaredly experimental track reaction would have been far more muted. If what was planned for the next stable-track baseline was a feature that had been in the experimental track for over 6 months (field-proven etc), AND the stable track had first enjoyed a life of a year ot more of "no breaking previously correct code" stability, WITH the nice extras you mention (optimizing, instrumenting, etc), again I think grumbles might have been less strident.

Schedules do matter, as does the perception of a stable, good porting target that is certain not to be due for obsolescence in six months.

P.S. The one area I'm less certain about is Deprecation. Phasing out lambda, map, and filter would please many but may have an equally strong counter-reaction. It's hard to tell (sometimes I think I'm the only one who like the functional stuff).

Again, over-lumping. I like map and filter well enough (though one can express them with list comprehensions, they're sometimes slightly more concise and faster). Not lambda though... the real functional stuff, sure, but lambda's underpowered and clunky.

P.S.S. I think the intensity of reaction to PEP 285 has to do with it being central to future programming style. It will affect and appear in programs across the board. Essentially, this proposal will be as pervasive as a change to the grammar would be.

These is some truth to that. Yet if it had not been introduced right into a release where many were looking forward to there being no such language-level changes, breaking the welcome perception of "some stability at last!", things might have been different. I think dual tracks for experimental and stable releases will help manage such things, giving the (not unfounded, mind you) perception of language stability to those who seek it (with an "actively supported release" -- instrumentation, optimizing, etc), AND bleeding-edge fast progress to neophiles (who are also so important to the community).

Alex