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 | ncoghlan at gmail.com | Brisbane, Australia
---------------------------------------------------------------
http://boredomandlaziness.blogspot.com
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4