On Sat, Feb 13, 2010 at 12:14 PM, "Martin v. Löwis" <mar...@v.loewis.de>wrote:
> >> 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? > > 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). > > >> 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. > > Regards, > Martin > > > Yes, if the trunk were the official master for lib2to3, then 3to2 would not change at all. If fixes to lib2to3 were immediately propagated to the trunk, 3to2 would benefit from that. I support lib2to3's integration with the trunk... it's too confusing otherwise and kind of defeats the idea of "trunk": if lib2to3 is provided with Python, then shouldn't its latest version be in Python's trunk? --Joe Amenta
_______________________________________________ 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
