2010/2/13 "Martin v. Löwis" <mar...@v.loewis.de>: >>> But isn't that just a theoretical property? I know that's how 2to3 >>> started, but who, other than the committers, actually accesses the 2to3 >>> repo? >> >> It's used in 3to2 for example. > > That doesn't really seem to be the case. AFAICT, 3to2 is a hg > repository, with no inherent connection to the 2to3 svn sandbox. It does > use lib2to3, but that could come either from an installed Python, from a > trunk/3k checkout, or from the sandbox. Correct?
It has to be from the sandbox (or trunk I suppose) because it requires changes that haven't been released. > > So if the 2.x trunk became the official master for (lib)2to3, nothing > would really change for 3to3, right? (except for the comment in the > readme that you should get 2to3 from the sandbox if the trunk copy > doesn't work; this comment would become obsolete as changes *would* > propagate immediately into the Python trunk). Right, except you would have to clone the entire history of Python in order to get at the trunk version. > >>> I would be much more supportive of that view if there had been a single >>> release of 2to3 at any point in time (e.g. to PyPI). Alas, partially due >>> to me creating lib2to3, you actually couldn't release it as an extra >>> application and run it on 2.6 or 2.7, as the builtin lib2to3 would take >>> precedence over the lib2to3 bundled with the application. >> >> It could be distributed under another name or provide a way to >> override the stdlib version. > > Sure. However, I'm still claiming that this is theoretical. The only > person who has shown a slight interest in having this as a separate > project (since Collin Winter left) is you, and so far, you haven't made > any efforts to produce a stand-alone release. I don't blame you at all > for that, in fact, I think Python is better off with the status quo > (i.e. changes to 2to3 get liberally released even with bug fix releases, > basically in an exemption from the "no new features" policy - similar to > -3 warnings). > > I still think that the best approach for projects to use 2to3 is to run > 2to3 at install time from a single-source release. For that, projects > will have to adjust to whatever bugs certain 2to3 releases have, rather > than requiring users to download a newer version of 2to3 that fixes > them. For this use case, a tightly-integrated lib2to3 (with that name > and sole purpose) is the best thing. Alright. That is reasonable. The other thing is that we will loose some vcs history and some history granularity by switching development to the trunk version, since just the svnmerged revisions will be converted. -- Regards, Benjamin _______________________________________________ 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
