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

Tim Peters tim.one@comcast.net
Tue, 09 Apr 2002 02:42:36 -0400

[Raymond Hettinger]

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

I agree with Alex that this is too lumped together; not everyone who dislikes a specific new feature dislikes all new features. Not even most, and not even close.

even they, have not chafed at the new email module or the addition of pydoc or unittest.

New library modules are indeed cool with most people.

Further, they will surely welcome a refactored parser,

That's of interest to almost nobody; PLabs wants it mostly to make it possible to do more intense program analysis without the code driving us insane (the current parser+codegen code is already pushed beyond its original design).

an exposed parser,

The audience for that is also small, unless it's an all-things-to-all-people kind of parser.

unified ints/longs,

People are definitely going to howl about finishing this one. People who used to strip the trailing 'L' from str(long) via str(long)[:-1] found themselves throwing away the last digit after str(long) stopped producing a trailing 'L'. What did they do instead? Almost every workaround I've seen amounted to doing repr(long)[:-1] instead. When repr(long) stops producing a trailing 'L' too, they're going to feel thrice screwed. That one's a special bitch, because it's neither the repr() nor the slice in isolation that creates the problem, so it's hard to give a sharp warning. Code is also going to break when, e.g., "1 << 100" stops producing 0, but at least that one can be warned about in a focused way.

and optimized variable access.

People do have a mild appreciation for speedups. Forget what you read about this on c.l.py, though: the true market for speedups is smaller than you'd guess for all the whining about this that goes on. Of course it doesn't help that all the speedup work that's gone on since 1.5.2 (and yes, there has been some, and some of it difficult) has been more than wiped out by the expense of new features. So far, CVS 2.3 is significantly faster than 2.2.1, but we've got lots of time to blow that too .

IOW, I believe that major, useful changes can be made without enraging the anti-change crowd. 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.

Stick around .

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 would enjoy a strong counter-reaction, but so far none of those are deprecated. I'm delighted to see you didn't put "reduce" in that list (almost always both more obscure and slower than the obvious loop).

It's hard to tell (sometimes I think I'm the only one who like the functional stuff).

You're not. Guido wants all of your kind to go away, though .