On Sat, Feb 13, 2010 at 12:14 PM, "Martin v. Löwis" <martin@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