[Python-Dev] Release Schedules (was Stability & change)
Guido van Rossum
Thu, 11 Apr 2002 21:25:35 -0400
> The anti-change [...] will surely welcome a refactored parser, an
> exposed parser, unified ints/longs, and optimized variable access.
Whoa, that's exactly where experimental releases would be good. You
picked a wonderful set of examples!
- Despite all the testing we can do, the new parser will have bugs.
(So did the nested scopes code, for several releases, and that was a
much less drastic overhaul than writing a whole new parser.) I'm
confident that we'll get it right eventually, but there will be some
pain for the early adopters; this time not in code breaking for
backwards incompatibility reasons, but random breakage because of
- The new parser will generate different code in certain corner cases
that are not 100% defined by the language spec. This can cause
differences in evaluation order, or other differences of
interpretation (maybe reject certain silly constructs), and that
will break *somebody's* code.
- Unified ints/longs is definitely going to break code. repr(2**100)
will no longer end in 'L', 1<<31 will return a different value,
0x80000000 will mean something different, and so on. We need to add
warnings for these things in 2.3, and only change their meanings in
2.4. But someone who skips a release will miss the warnings. And
we can't add the warnings to 2.2.2 or 2.1.4 (too disruptive).
- Optimized variable access is definitely going to change semantics in
> IOW, I believe that major, useful changes can be made without
> enraging the anti-change crowd.
I'm not so sure. :-(
> Improving the product, fixing 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.
I wish that were true. Adding bool doesn't change any syntax at all.
> Raymond Hettinger
> 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).
Not worth the fight.
> 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.
Maybe. And then again, there are people who believe that no function
should return a bool -- so why would they care. :-)
--Guido van Rossum (home page: http://www.python.org/~guido/)