Hey folks, I'm going to write a PEP for inclusion of lib3to2 in the standard library for 3.2 and above. Before do, though, do people have any quick thoughts about it? My inclination is to get it stabilized beforehand (perhaps during another GSoC) by fleshing out the fixer that warns about backwards-incompatible features in Python 3 and by finishing up the fix_imports2 fixer, probably involving a rewrite. http://bitbucket.org/amentajo/lib3to2 is where the source is hosted (there's a separate branch for 3.1) http://www.startcodon.com/wordpress/?cat=8 is where I blog about it. http://pypi.python.org/pypi/3to2 is the PyPI page that has both of those links. --Joe Amenta
What would be the advantage of having it in the stdlib? It would put a stop on further development once it's been released as such, which strike me as a bad idea for a heuristic tool like 3to2. I would expect that you will continue to add more rules (and more exceptions) to it for the foreseeable future. You'll probably want to continue to maintain it as a 3rd party library so you can release those rules easily. Sounds like a bad idea to put it also in the stdlib, since you can't effectively update the stdlib version. --Guido On Sun, Feb 21, 2010 at 1:00 PM, Joe Amenta <amentajo@msu.edu> wrote:
-- --Guido van Rossum (python.org/~guido)
Joe Amenta wrote:
I do: it seems too early to me. Before it is added, I'd like a see a significant success story of its use. When lib2to3 was added, both Guido and Benjamin were also concerned that it is too early, and that 2to3 would change over time, so somehow freezing the API was undesirable. I personally felt more comfortable: I had ported a large project myself (Django), so I knew what little API I used could actually help porting, and also that the set of fixers implemented was useful (although the initial port had to made quite some work-arounds for missing and incorrect fixers which aren't need today anymore). So find somebody to write a large project in Python 3, and then have them backport it with 3to2 :-) Seriously, find somebody who ports a large Python 2 project (e.g. with 2to3) in a burn-your-bridges fashion, and then uses 3to2 to provide 2.x releases. In addition, I recall talk (again from Guido and Benjamin, and perhaps also Collin) that they would prefer all of this to be rewritten as a general rewriting library, where 2to3 and 3to2 would just be specific sets of transformations. If that is still the case, I think such a PEP should address that (and the code should actually be refactored
I think stabilization must require applications. So any further development should focus on that. In my experience, this means that you'll have to do the porting yourself, and then offer patches. Approach some package author(s) whether they would be interested in using 3to2 if you did the work for them, and then pick one such project as the litmus test. My expectation is that you'll find a need for additional changes in doing so. Regards, Martin
What would be the advantage of having it in the stdlib? It would put a stop on further development once it's been released as such, which strike me as a bad idea for a heuristic tool like 3to2. I would expect that you will continue to add more rules (and more exceptions) to it for the foreseeable future. You'll probably want to continue to maintain it as a 3rd party library so you can release those rules easily. Sounds like a bad idea to put it also in the stdlib, since you can't effectively update the stdlib version. --Guido On Sun, Feb 21, 2010 at 1:00 PM, Joe Amenta <amentajo@msu.edu> wrote:
-- --Guido van Rossum (python.org/~guido)
Joe Amenta wrote:
I do: it seems too early to me. Before it is added, I'd like a see a significant success story of its use. When lib2to3 was added, both Guido and Benjamin were also concerned that it is too early, and that 2to3 would change over time, so somehow freezing the API was undesirable. I personally felt more comfortable: I had ported a large project myself (Django), so I knew what little API I used could actually help porting, and also that the set of fixers implemented was useful (although the initial port had to made quite some work-arounds for missing and incorrect fixers which aren't need today anymore). So find somebody to write a large project in Python 3, and then have them backport it with 3to2 :-) Seriously, find somebody who ports a large Python 2 project (e.g. with 2to3) in a burn-your-bridges fashion, and then uses 3to2 to provide 2.x releases. In addition, I recall talk (again from Guido and Benjamin, and perhaps also Collin) that they would prefer all of this to be rewritten as a general rewriting library, where 2to3 and 3to2 would just be specific sets of transformations. If that is still the case, I think such a PEP should address that (and the code should actually be refactored
I think stabilization must require applications. So any further development should focus on that. In my experience, this means that you'll have to do the porting yourself, and then offer patches. Approach some package author(s) whether they would be interested in using 3to2 if you did the work for them, and then pick one such project as the litmus test. My expectation is that you'll find a need for additional changes in doing so. Regards, Martin
participants (3)
-
"Martin v. Löwis" -
Guido van Rossum -
Joe Amenta