Bugs in CPython 3.1.1 [wave.py]

[Steven D'Aprano]

On Tue, 12 Jan 2010 23:42:28 +0100, Alf P. Steinbach wrote:

> * André:
>> On Jan 12, 9:33 am, "Alf P. Steinbach" <al... at start.no> wrote:
>> 
>>> Well, this is for my Python (actually, beginning programmer) writings,
>>> at
>>>
>>>    http://tinyurl.com/programmingbookP3
>>>
>>>
>> Thanks for writing this book.  I just had a quick look at the beginning
>> of it where you write:
>> ===
>> As of this writing two main variants of the Python language are in use,
>> namely
>> Python 2.x and Python 3.x (versions 3.0 and greater). Mostly they’re
>> the same but the
>> effect of e.g. the / division operator changed in 3.0, so in practice
>> it’s hopeless to try
>> to create programs that work the same – or even just work – with both
>> variants.
>> ===
>> Notwithstanding your experience (finding a bug in wave.py), this
>> statement is false.  There are plenty of non-trivial applications that
>> have been ported so that they work "as is" with both Python 2.x and
>> Python 3.x.
> 
> I'm sorry but your conclusion does not follow from the fact that you
> point out.
> 
> It is hopeless, especially for a newbie, to create correct Python
> 2.x+3.x compatible code, except totally trivial stuff of course.

So you allege, but André points out that there are existing, non-trivial 
applications that work unmodified under both Python 2.x and 3.x. For 
example, CherryPy:

http://www.cherrypy.org/wiki/WhatsNewIn32

You're welcome to your own opinion, of course, but not your own reality, 
and the reality is that it is NOT "hopeless" to write correct Python code 
that operates under both 2.6 and 3.x. It's not hopeless because it's been 
done. You might even be able to target versions older than 2.6 if you 
really work at it, as CherryPy does.

Continuing to assert something which is demonstrably untrue simply means 
you lose credibility among those who are familiar with Python.



> This due most of all to the language differences, but also to the fact
> that there are PLENTY of libraries that haven't yet been ported, like
> PIL...

Right, and if your application requires PIL, then it is impossible, but 
for the countless applications that *don't* require PIL, it makes no 
difference at all.


[...]
> The problem is writing code that is correct with both languages, which
> is hopeless when e.g. integer division changes underfoot, like "/"
> meaning two different things depending on the language, print syntax
> changing, so forth.

from __future__ import division
from __future__ import print_function
from future_builtins import hex, map  # or whatever


Not even close to hopeless.




-- 
Steven