I am proud to announce the third alpha release of 3to2: 0.1a3. Release notes can be found in the RELEASE file.
Note that the Python 3.1 branch requires patching lib2to3 to be able to run the unpacking fixer, which is disabled by default for this reason. If you have no problems patching lib2to3 in this way and wish to have the fixer enabled by default, you may manually edit lib3to2/fixes/fix_unpacking.py and delete the line that says “explicit = True” before running setup.py. (If you do this after running setup.py, then you will have to run it again.)
New to this version of 3to2 is a slightly enhanced Makefile. Users of UNIX-like machines can run “make install-local” to install 3to2 to $HOME/.local, “make test-local” to install 3to2 locally and run the test suite, and “make uninstall-local” to remove 3to2′s presence from $HOME/.local
Python 2.7: gzipped tarball is available at bitbucket, and there is also a mercurial branch of the source. 2.7 releases will be tagged versions of the trunk.
Python 3.1: gzipped tarball is available at bitbucket (if you downloaded this before 4:00 PM EDT today (Oct 28), please re-download. It has been updated. Thank bitbucket.), and there is also a mercurial branch of the source. 3.1 releases will be discreet, as 2to3 is run on the 2.7 branch every release.
Also new to this version is a PyPI registration for the 3.1 branch.
One final note I want to make is that the 3.1 branch can be installed side-by-side with the 2.7 branch, as the 3.1 branch calls the 3to2 executable “3to2_31″. I don’t think that I want to change that, but please let me know if this seems like too much of a burden, as I am open to completely turning 3to2 upside-down based on feedback from the (majority of the) community.
So my 3to2 article for PyMag has been submitted with the first set of technical revisions. I have been hinted that it may show up as soon as the October edition, but I think that remains to be seen.
During the process of writing it, I found another bug and some inconsistencies with the documentation that I fixed up… heh.
This week, I created a fixer and test cases for dict comprehensions and set comprehensions. The fixer does:
{a:b for c in d [if e]} fixes to dict((a, b) for c in d [if e])
{a for b in c [if d]} fixes to set(a for b in c [if d])
I am currently in the process of moving all guidelines for “Things 3to2 does not accept” (from the post of the same name and from stuff I have accidentally left in my head) to the bitbucket issues tracker. Some will be marked “wontfix” immediately due to the limitations inherent in 3to2, but the point is that there will be a separate issue for each individual thing that 3to2 is known not to be able to deal with properly, with its own separate little discussion thread.
I don’t know why I didn’t do this earlier.
I have a long weekend coming up here. I have an article to finish writing for PyMag, I have a chapter of Statistics to read, and Statistics homework to do. 3to2 is my next priority, then finishing up my WSGI app for CSE 491 (what it should be doing is importing jinja2_form.process). As you can see, 3to2 is near the bottom of that list, so there will probably be no 3to2 updates for a while.
Last week, I had a lot of things to do and did not contribute any new code to 3to2. I will make the effort to finish the second part of fix_unpacking and make another release once that happens. Here is the updated release plan:
0.1a1: First alpha release
0.1a2: Print function -> Print statement fixer added, minor distribution bugs fixed
0.1a3: Extended Iterable Unpacking fixer added
0.1a4: 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.
Final 0.1 release will be prompted only by feedback (positive or negative) from a large enough group of people that I become confident with widespread stability.
Note to potential testers: 3to2 will not write any changes to files unless you explicitly tell it to. At this stage of 3to2′s development, even if you just run 3to2 on a py3k project and report “It didn’t crash!”, then that would contribute to the process greatly. Thanks in advance!
I’ve fixed the most obvious use case for the extended iterable unpacking from last post… or so I think. I’m on a laptop that doesn’t have the right environment for the 2to3 version that allows me to properly test my code. That means that what I will commit (as soon as BitBucket comes back up and I am awake) is most likely bug-ridden, even though it most likely looks a lot like the final part will look.
What remains to be fixed is the “for i, *b in some_iter:” line, which I have specified, just not implemented.
Edit: The code was indeed bug-ridden, but all has been cleaned up. I made the “*z, = some_iter” case less special in the test case to keep an already monstrous-looking line of code from becoming a disaster to maintain. I can’t imagine when that case would be used other than with code generators, as it is syntactically equivalent to “z = list(some_iter)”, so in my opinion, it can afford the extra namespace butchering.