On 12/13/2011 6:36 PM, exar...@twistedmatrix.com wrote:
On 09:37 pm, tjre...@udel.edu wrote:
On 12/13/2011 10:54 AM, Vinay Sajip wrote:
I started writing a tool today, tentatively called '2to23', which
aims to do
this. It's basically 2to3, but with a package of custom fixers in a
package
'lib2to23.fixers' adapted from the corresponding fixers in lib2to3.
When, some year in the future, people want to drop Python 2
compatibility from their Python23 code, they will need a 23to3 tool.
No, they will not.
Yes they will, if you read my conditional statement properly.
Anyway, quibbling over the meaning of 'need' is quite useless. It has
two shades of meaning: lack of something required, and lack of something
desired. You could have made the valid part of your point without
starting off as you did.
But I already implied that removal is less urgent when I wrote "When,
some year in the future...".
They only need a 2to3 or 2to6 tool because Python 2
and Python 3 are not compatible with each other, but they want one
program to be valid in Python 2 and Python 3 simultaneously.
They *need* the extra stuff inserted. They do not *want* to insert by
hand. So by your narrow meaning of 'need', one could say that having the
insertion done by program is a want, not a need.
When they decide they no longer care about Python 2, they can just stop
taking care to keep their program valid as Python 2 and only take care
to keep it a valid Python 3 program. There's no specific change to make,
just a different approach to take with future maintenance.
You might say that they will *want* to immediately discard all of their
legacy Python 2 support code. I suspect many of them will not want this;
but either way it's a want, not a need.
If and when someone wants the extra stuff removed to eliminated both the
extra run-time and mental overhead of having it around, and they do not
want to remove it by hand, they will want and therefore need in the more
general sense to have it done automatically. In both cases, addition and
removal, the process is tedious and error-prone if done by hand.
--
Terry Jan Reedy
_______________________________________________
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
