On Tue, 12 Jan 2010 23:42:28 +0100, Alf P. Steinbach wrote: > * André: >> On Jan 12, 9:33 am, "Alf P. Steinbach" <al...@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 -- http://mail.python.org/mailman/listinfo/python-list
