Bugs in CPython 3.1.1 [wave.py]
steven at REMOVE.THIS.cybersource.com.au
Wed Jan 13 08:35:43 CET 2010
On Wed, 13 Jan 2010 06:39:53 +0100, Alf P. Steinbach wrote:
> Then be a little critical and think about, what problems could it be
> that, in spite of that to you apparent simplicity, hinders the
> widespread adoption of Python 3.x?
(1) Most Linux distributions still come standard with Python 2.5 or
older, not even 2.6. Consequently, most developers are still writing for
2.5 or even 2.4 and won't even consider 3.1 until the distros provide it
as standard. Apple also comes standard with 2.5, and I believe that when
hardware vendors supply it on Windows systems, it's typically 2.5 also.
(2) Because of the negativity of people overstating the differences
between 2.x and 3.x.
(3) And because of the slow pace at which major third-party libraries
have supported 3.x, which is mostly a matter of man-power rather than
It is difficult to support both 2.4 and 2.5, because 2.5 introduces a
whole lot of excellent features that 2.4 doesn't have. I know, because
I've tried. (After spending much effort trying to develop my own
compatibility layer, I eventually decided to just stop supporting 2.4.)
Do people go on and on and on about how it is "hopeless" to support
multiple versions of 2.x? No, of course they don't. It requires extra
work, and it's inconvenient, but it can be done and it is done.
Trying to support everything from 2.0 to 3.1 would be horrible, but not
because 3.1 is so different from 2.x. The oldest versions of the 2.x
series lack so many features that have become fundamental to modern
Python: no generators, no decorators, no iterators, and others. But
supporting 2.6 and 3.0/3.1 is nothing as so hard. I would argue that,
fundamentally, there are fewer differences between 2.6 and 3.1 than
between 2.1 and 2.5.
Upgrading a major application or library to support 3.x is a big job,
simply because *any* re-factorising of a major application is a big job.
But writing a new application supporting 2.6 and 3.x from scratch is a
much simpler process. Likewise writing small scripts.
To say as you do that the change in the semantics of the division
operator makes the task "hopeless" is simply ridiculous. It's a one-line
fix: "from __future__ import division" at the top of each module, and you
now have identical semantics in both 2.6 and 3.x.
Nobody is trying to understate the complexity of writing a large
application that supports both 2.6 and 3.x, or of taking an existing
library written for 2.5 and upgrading it to support 3.1. But the
magnitude of these tasks is no greater (and potentially smaller) than
supporting (say) 2.3 through 2.5. To describe it as "hopeless" is simply
mistaken and weakens your credibility.
More information about the Python-list