<div class="gmail_quote">On Sat, Feb 13, 2010 at 12:14 PM, "Martin v. Löwis" <span dir="ltr"><<a href="mailto:martin@v.loewis.de">martin@v.loewis.de</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">>> But isn't that just a theoretical property? I know that's how 2to3<br>
>> started, but who, other than the committers, actually accesses the 2to3<br>
>> repo?<br>
><br>
> It's used in 3to2 for example.<br>
<br>
</div>That doesn't really seem to be the case. AFAICT, 3to2 is a hg<br>
repository, with no inherent connection to the 2to3 svn sandbox. It does<br>
use lib2to3, but that could come either from an installed Python, from a<br>
trunk/3k checkout, or from the sandbox. Correct?<br>
<br>
So if the 2.x trunk became the official master for (lib)2to3, nothing<br>
would really change for 3to3, right? (except for the comment in the<br>
readme that you should get 2to3 from the sandbox if the trunk copy<br>
doesn't work; this comment would become obsolete as changes *would*<br>
propagate immediately into the Python trunk).<br>
<div class="im"><br>
>> I would be much more supportive of that view if there had been a single<br>
>> release of 2to3 at any point in time (e.g. to PyPI). Alas, partially due<br>
>> to me creating lib2to3, you actually couldn't release it as an extra<br>
>> application and run it on 2.6 or 2.7, as the builtin lib2to3 would take<br>
>> precedence over the lib2to3 bundled with the application.<br>
><br>
> It could be distributed under another name or provide a way to<br>
> override the stdlib version.<br>
<br>
</div>Sure. However, I'm still claiming that this is theoretical. The only<br>
person who has shown a slight interest in having this as a separate<br>
project (since Collin Winter left) is you, and so far, you haven't made<br>
any efforts to produce a stand-alone release. I don't blame you at all<br>
for that, in fact, I think Python is better off with the status quo<br>
(i.e. changes to 2to3 get liberally released even with bug fix releases,<br>
basically in an exemption from the "no new features" policy - similar to<br>
-3 warnings).<br>
<br>
I still think that the best approach for projects to use 2to3 is to run<br>
2to3 at install time from a single-source release. For that, projects<br>
will have to adjust to whatever bugs certain 2to3 releases have, rather<br>
than requiring users to download a newer version of 2to3 that fixes<br>
them. For this use case, a tightly-integrated lib2to3 (with that name<br>
and sole purpose) is the best thing.<br>
<br>
Regards,<br>
<font color="#888888">Martin<br>
</font><div><div></div><div class="h5"><br>
<br></div></div></blockquote><div><br></div><div>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.</div>
<div>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?</div>
<div>--Joe Amenta</div></div>