Lately, there seems to be a lot of posts trying to encourage people to port their apps/libraries/modules to Python 3. I'd like to add my voice and perhaps, use as a reminder this old post: more than 2 years ago, Crunchy was made compatible with Python 2.4, 2.5, 2.6 ... and 3.1. At the time, we made the decision to not follow what seem to be the official recommendation, namely to have one code base based on 2.x and use the 2to3 tool to do the automatic translation. Instead, we decided to have a single code base, which seems the way people are doing it these days. There were of course some challenges, especially as we kept compatibility all the way back to Python 2.4: since Crunchy puts a Python interpreter inside your browser and manipulates what's there, regardless of the encoding, it has to be able to do a lot of string (and bytes for 3.x) manipulations, as well as dealing with incompatible syntax for handling exceptions, etc. when running the code that is fed to it. This was done when there was very little known about best practices for porting from 2.x to 3. Partly as a result, Crunchy's code is not the best example to look at when it comes to doing such a port ... but it certainly demonstrated that it was possible to port a non-trivial program with a tiny team. Now, the situation is quite different, and many more projects have been ported, and you can benefit from their experience.
So, what are you waiting for?
I'm waiting for motivation !
ReplyDeleteSo far, in my opinion there's nothing in python 3 that warrants the effort of porting.
Backward compatibility was broken to please the python core developers, not to solve a user problem. I can sort of understand how some of the new unicode stuff might make sense (despite having the effect of making often used easy stuff more difficult, and less often used hard stuff easier), but jokes like making "print" a function instead of a statement is just plain stupid: it breaks just about every code out there (even if it's just commented out debug code) and if I really wanted it in a function (I don't! Why would I?) I can simply wrap it in one.
So porting to python3 boils down to first investing (lots of) effort to arrive at something that works slower and (if you need to support multiple versions of python in the same code base) looks less readable. In what parallel universe would this make sense?
I can't help but wonder what the core devs were smoking when they came up with python 3.
numpy, scipy, matplotlib.
ReplyDeleteUm, Anonymous #2 - numpy, scipy, and matplotlib on Python 3? Done, done, and done.
ReplyDeleteAnonymous: a cleaner standard library is one bonus. There's heaps of smaller cleanups, which don't seem much by them selves, but they are.
ReplyDeleteJust that there is now one type of object is a pretty good cleanup.
Cleanups aren't so much features, and are not given the same weight by many people, but cleanups are harder and provide some lovely things.
u'' is missing, which is another cleanup.
The major incentive is that python2 is now a legacy platform. So if you have commercial projects running on it, you need to take the maintenance of python2 into consideration. The python community as a whole now seems to be moving towards python 3. With most major packages having been ported.
Finally, the performance of python3.3 is improving. There are a whole lot of improvements compared to python 3.2, and as more people start putting python 3 into production. Strings in particular in python3.3 are faster and use less memory. There are also some advanced optimization projects going on that have the potential to make py3k 1.3-2.2 times faster.
cheers