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

[Alex Martelli]

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