On Nov 3, 2009, at 10:54 AM, Guido van Rossum wrote:
Ouch. sets. I'm guessing you are referring to code that was still using the pre-2.4 sets.py module? Yes, that must have been painful.
Indeed. :) What's nice though is that these changes could be made for the Python 2.5 branch and didn't have to wait until 2.6 (e.g. sha/md5 - > hashlib, sets -> builtin-set).
What was actually most painful about this were all the tests that were checking stdout/stderr for clean subprocess runs. The DeprecationWarnings that were produced killed us for a long while because so many of those tests failed.
It's actually quite difficult to suppress DeprecationWarnings across the board, especially when you have lots of subprocess that call third party code (where most of the deprecated code lived in, and which we couldn't change). We added filterwarnings where we could, and called subprocesses with -W every place we thought we needed to but we never did kill them all off. I think a $PYTHONWARNING environment variable might have helped here.
Given another week or so I think we would have made it to Python 2.6, but I'm not at all confident that that would have been a good enough platform to attempt an upgrade to Python 3, even if all of our very numerous large dependencies were available for Python 3. Maybe it wouldn't be so bad, but my recent experience informs me that I'm probably being too optimisticrather than too pessimistic.There are two stages of porting to 2.6 you have to go through. The first one, which you would probably have reached in that week, is running on 2.6 period. You can then release your code for the benefit of others wanting to use it on 2.6.
Yep.
But the second stage, which can take much more time (depending on the state of your code base) is to run on 2.6 *free of warnings with the -3 flag on*. You pretty much have to consider this a separate port, and it is here where you do much of the prep work for 3.x (at least for Python code -- for C extensions it's not so clear). The good news is that you can claim 2.6 support before you've even started this stage; the other good news is that doing this right will really help you prepare for 3.x. And in most cases you can even (with some effort) maintain compatibility with 2.5 or even 2.4 -- though you may have to work around some things like the md5 and sha warnings. The bad news is that this stage may well take more time than porting from 2.4 to 2.6.
We have another window for this (since it's all open source I don't mind talking about it) when the next version of Ubuntu comes out. Running with the -3 is a great idea, and something I will definitely try after finishing the straight 2.6 port.
-Barry
PGP.sig
Description: This is a digitally signed message part
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
