Edit: Thanks to Benjamin Peterson, this is no longer an issue in the latest revision of 2to3. Look for revision 75081 to be merged into python trunk from svn.python.org/sandbox/trunk/2to3/lib2to3, or manually modify your working copy of python 2.7 to include the lib2to3 from there if you can’t wait.
—
Thanks to a bug report by donspaulding on bitbucket, it is now clear that 3to2 will have some serious problems with PEP 3132-style extended iterable unpacking. This is unfortunate, because despite my best efforts, I have so far been unable to modify 3to2′s grammar in such a way to give me the privilege of writing a syntactical fix for the bug. The way it is right now, 3to2 explodes with a ParserError on lines like this:
a, *b, c = range(5)
The * is what does it. PEP 3132′s implementation required adding “star_expr: ['*'] expr” into the grammar and modifying a few lines to use it instead of expr. My attempt at copying these changes to the grammar created another error. I don’t have much expertise in this dark corner of Python, but it appears that the definition for “arglist” would be ambiguous if one replaces “comparison: expr (comp_op expr)*” with “comparison: star_expr (comp_op star_expr)*”, because there would be ambiguity in resolving “*name” found in an arglist: should it be a “starred expression”, or should it be a “*” followed by “name”, indicating that “name” should be a tuple of all positional arguments not named? (Furthermore, should “**name” be a “*” followed by a “starred expression”, or “**” followed by “name”, indicating that “name” should be a dict mapping all keyword arguments not named?)
I find myself at a loss. I do not know how I would even start going about fixing this dilemma. Until this bug is fixed, all code that uses the extended iterable unpacking syntax will make 3to2 stop parsing and give up, even if it had other fixes it could have done.
I am proud to announce the second alpha release of 3to2: 0.1a2. New features from 0.1a1:
print function -> print statement added as the default print behavior (the old behavior of adding “from __future__ import print_function” to the top of a module works if enabled explicitly with -fprintfunction)
removed a few lines that were causing unnecessary DeprecationWarnings
Added a 3.1 branch; the trunk for that branch is available at bitbucket. Everything was run through 2to3, changes were made to code that explicitly referred to a version number, and the test suite was run to make sure it still passed.
Python 2.7: gzipped tarball is available at bitbucket, and there is also a mercurial branch of the source.
Python 3.1: gzipped tarball is available at bitbucket, and there is also a mercurial branch of the source.
Hi all,
I’ve finished the print function -> print statement fixer now, and that will be the center part of the second alpha release. Now might be an appropriate time to have a plan for the future of the 0.1 version of 3to2:
0.1a1: First alpha release
0.1a2: Print function -> Print statement fixer added, minor distribution bugs fixed
0.1a3: Features fixer is generic and relatively easily expandable
0.1b1: Cleanups on fix_imports and fix_imports2 make them worthy of being enabled by default
0.1b2: TBD, also more test cases.
…
0.1 final: I won’t be ready to do a final release of 0.1 until I have more feedback from people with real 3.x code, so that I can get a better feel for how well it works on real code, with all sorts of cases I probably haven’t considered yet. (Of course, I’m sure people won’t bother with trying it out until there’s a final release of some version, so I may end up doing a final release of 0.1 when I feel more comfortable with the breadth of the test cases, it’ll just take longer)
Once all the paperwork gets settled (it’s out of my hands, for now), I’m going to be working on 3to2 for an independent study. A part of what that means is that I’m going to do a blog post each week on what has been accomplished that week. Another part is that I’m going to be spending more development time on 3to2 again. Stay tuned for more details.
For now, I’m going to keep everything related to 3to2 on this blog under the category “3to2″. I perceive that this will not be an issue, considering that the bitbucket site is the home of the 3to2 source, issue tracker, and tarball downloads. However, if there’s enough call for moving the 3to2 blog to a different URL (or I decide to do so on a whim), I have the database framework in place to do so.
Edit: I am now officially doing the independent study. More posts to come!