Neal Norwitz wrote: > I'm sure this tool wouldn't be perfect, but if it did most of the > work, would that change opinions?
To me, the main objection seems to revolve around the fact that people would like to be able to "future-proof" Python 2.x code so that it will also run on Py3k. We're steadily accumulating collections of "old ways" and "new ways", and the Py3k transition should mainly be about deleting the "old ways". That is, if the way something is going to be done is to change in Py3k, the new alternative should already be in place towards the end of the 2.x series, so that Py3k is only a potential problem if people are still using the "old ways". Maybe "from __future__ import py3k" would do the trick ;) Cheers, Nick. -- Nick Coghlan | [EMAIL PROTECTED] | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com _______________________________________________ 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