3to3 tool for 3.x to 3.x+n version migrations
Now that we've developed 2to3 and 3to2 I've started wondering "what next?" and realized that we could use a 3to3 tool to apply the relatively few and relatively simple sets of code changes to deal with library reorganizations, renaming, parameter changes, default behavior changes, other deprecations that have an equivalent, etc. The list of migrations to go between any given 3.x to another 3.x release would likely be pretty small. Just tossing the idea out there incase someone is interested. I expect the hard work is already done. thoughts? -gps
On 12/4/2010 11:37 PM, Gregory P. Smith wrote:
I had a vague thought like this recently. I am glad you formulated it as a coherent thought and posted it. Such a tool should also make note of deprecated construct that it recognizes but cannot fix. One problem with runtime DeprecationWarnings is that test suites do not always have 100% coverage, and code not executed will not issue a warning. -- Terry Jan Reedy
When we were discussing yield from, Guido mentioned that it would be nice to have some way to test out things like that before committing all of Python to it. One way to do that might be if someone adapted it into a "4-to-3" to let you rewrite yield from, for example, in its full Python 3.2 expansion form. In other words, the n-to-n engine could be used as a general purpose macro system. Perhaps it could even useful for the internationalization project mentioned recently? The advantage of having the macro engine separate from Python proper would be that this way these extensions never get popular, and so 99% of Pythonistas never have to worry that maybe someone redefined "for item in items:" in their module using C-style #macros. It would exist solely as a way of testing out the various proposals that are made on Python-ideas and elsewhere before having to commit to them or of translating Python programs into a native language for younger, non-English native programmers. -- Carl
On Sun, Dec 5, 2010 at 5:46 PM, Carl Johnson < cmjohnson.mailinglist@gmail.com> wrote:
I am in favor of keeping this in some form as well (but would like to see some changes made, it's design reflects a sort of one-offness). I have used it in the past for broad codebase manipulations at a sort of package compile time. Using it for yield from seems brilliant as well. -- Zachary Burns (407)590-4814 Aim - Zac256FL
On 12/4/2010 11:37 PM, Gregory P. Smith wrote:
I had a vague thought like this recently. I am glad you formulated it as a coherent thought and posted it. Such a tool should also make note of deprecated construct that it recognizes but cannot fix. One problem with runtime DeprecationWarnings is that test suites do not always have 100% coverage, and code not executed will not issue a warning. -- Terry Jan Reedy
When we were discussing yield from, Guido mentioned that it would be nice to have some way to test out things like that before committing all of Python to it. One way to do that might be if someone adapted it into a "4-to-3" to let you rewrite yield from, for example, in its full Python 3.2 expansion form. In other words, the n-to-n engine could be used as a general purpose macro system. Perhaps it could even useful for the internationalization project mentioned recently? The advantage of having the macro engine separate from Python proper would be that this way these extensions never get popular, and so 99% of Pythonistas never have to worry that maybe someone redefined "for item in items:" in their module using C-style #macros. It would exist solely as a way of testing out the various proposals that are made on Python-ideas and elsewhere before having to commit to them or of translating Python programs into a native language for younger, non-English native programmers. -- Carl
On Sun, Dec 5, 2010 at 5:46 PM, Carl Johnson < cmjohnson.mailinglist@gmail.com> wrote:
I am in favor of keeping this in some form as well (but would like to see some changes made, it's design reflects a sort of one-offness). I have used it in the past for broad codebase manipulations at a sort of package compile time. Using it for yield from seems brilliant as well. -- Zachary Burns (407)590-4814 Aim - Zac256FL
participants (4)
-
Carl Johnson -
Gregory P. Smith -
Terry Reedy -
Zac Burns