[Python-Dev] Release Schedules (was Stability & change) (original) (raw)
Guido van Rossum guido@python.org
Thu, 11 Apr 2002 21:25:35 -0400
- Previous message: [Python-Dev] Release Schedules (was Stability & change)
- Next message: [Python-Dev] 2.2.1c2 RPMs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
[Raymond Hettinger]
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 parser bugs.
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 end cases.
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/)
- Previous message: [Python-Dev] Release Schedules (was Stability & change)
- Next message: [Python-Dev] 2.2.1c2 RPMs
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]