On 01/14/10 11:08, Alf P. Steinbach wrote: > * Daniel Fetchinson: >> >> Nobody is deliberately trying to keep people from porting! I think you >> misunderstand what is being said, these two statements are very >> different: (1) single code base working on both python versions (2) >> creating a second code from a code so that the second code works with >> python 3 and the first one with python 2. Statement (2) is about >> porting, statement (1) is about something else. >> >> Having said all that I actually seriously doubt (probably in agreement >> with you) that Alf is able to write good and helpful material on the >> relationship between python 2 and 3, porting, migrating, etc, based on >> his emails :) > > You're mostly absolutely right. :-) > > I think it's OK to write things like "It's possible to travel to the > moon" and "It's very difficult to travel to the moon", because those are > just general observations -- even though an astronaut may disagree > with the latter stm. > > But in order to write about the design of rockets, planning, economics, > the physics of it, life support, etc., all the nitty gritty details > about traveling to the moon so as to enable someone to do it, one needs > to have done it. > > And so far I haven't done that 2.x/3.x compatible code thing except for > some very trivial stuff. It so happened that what I wrote in Oct 2009 or > whenever it was, about "/", was verified just now by stumbling upon the > "/" bug in [wave.py]. But that apparent detail was again just a general > observation based on common sense and experience with similar > differences in other languages, much like "you can expect problems if > you have a big hole where your rocket's nose tip should be". To write > about actual porting, version-compatible code, etc., so that it's useful > to the reader would or will require far more. I'm probably not going to > do that. > > There are however some comments about 2.x/3.x differences, e.g. about > "range" and "/", and I'm just now progressing into territory where I'll > mention "long". > > And I think that those comments constitute good and helpful material on > the relationship between 2.x and 3.x?
The GNU Build System have succeeded in producing a program that can write shell scripts (./configure) that works across any shell implementation and any shell version on any OS (even on Windows with Cygwin) generally without the need for manual tweaking. It is common knowledge that a carefully written python scripts is easily portable between different OS-es, and since there is only one "shell" to support[1], why do you think this scenario is harder than what GNU Build System developers were facing? They have shown that it is "possible" to write a complex *and* portable shell script; why do you think it is "impossible" to write a complex and portable python script? Though keeping everything in one code base may often be difficult and only of little practical benefit, it is not impossible. Modern version control systems makes creating a fork not-so-difficult[2]; and maintaining two or more codebase is much cheaper nowadays than they used to be. [1] we're ignoring other python implementations since they haven't targeted 3.0; but anyway due to the much better defined standard, alternative implementations doesn't pose much difference except for occasional lack of the newest feature on many cases [2] though not, by any definition, "easy"; but at least it's often easier to fork than to keep things in one code base. Another, better, alternative is to write a program that transform a human readable code to portable code; which is what 2to3 is about. -- http://mail.python.org/mailman/listinfo/python-list
