Bugs in CPython 3.1.1 [wave.py]

[Steven D'Aprano]

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 
technical difficulty.


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.




-- 
Steven