[Python-Dev] PEP 385 progress report

[Joe Amenta]

On Sat, Feb 13, 2010 at 12:14 PM, "Martin v. Löwis" <martin at 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-dev/attachments/20100213/0815f263/attachment-0001.htm>