I don't know if you're done with this already, but there's a lot of experience suggesting such sweeps are quite dangerous. In the past, whenever a sweep across the entire stdlib was done, it's always caused a few breakages, some of which didn't get caught until the next release.
Things to worry about with these two changes:
raise X, y -> raise X(y): this is incorrect if y is a tuple; *only* if it's a tuple, the correct translation is raise X(*y). But 2to3 can't know that (unless the tuple is written out in place).
except X as y: in 3.0 this has different semantics -- y is explicitly deleted at the end of the except block. I don't know if this is also the semantics implemented in 2.6 (I think it should be), but again this can cause som equite subtle breakages that are hard to catch automatically.
And since both of these are about exceptions, there's a high likelihood that some occurrences are not reached by a unittest.
IOW, while I'm not dead set against it (I agree with your motivation in principle) I worry that in practice it may destabilize things., and would prefer a different approach where these things are only changed when someone is revising the module anyway.
On Feb 17, 2008 8:57 AM, Christian Heimes email@example.com wrote:
Good evening everybody!
I like to run the 2to3 tool with raise and except fixers over the 2.6 sources. The raise fixer changes "raise Exception, msg" to "raise Exception(msg)" and the except fixer replaces "except Exception, err" by "except Exception as err". In my humble opinion the Python stdlib should give proper examples how write good code.
During the migration period from the 2.x series to 3.x we have two obvious ways to write code. Let's stick to the new and preferred way.
Oh and please use the new syntax for patches, too. It makes my job with svnmerge a little bit easier.
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/guido%40python.org