[Python-checkins] r64360 - python/trunk/Lib/lib2to3/refactor.py

"Martin v. Löwis" martin at v.loewis.de
Wed Jun 18 09:24:25 CEST 2008


>> Please never commit to python/trunk/Lib/lib2to3.
>> Instead, commit to sandbox/trunk/2to3, and merge
>> that using svnmerge.
> 
> Could you explain that policy? Why isn't 2to3 maintained in the
> trunk but in the sandbox? Or maybe more general: Where can I find
> more information on the svn directory layout?

It started off as a sandbox project, also with the intent of releasing
it separately. At PyCon 2008, I restructured it introducing lib2to3,
which I then copied into the trunk, and from there into the 3k branch.
The official sources still remain in the sandbox:
a) for historical reasons, because that's where the main 2to3
   contributors commit to (who might not even have a trunk checkout,
   only a 2.5 installation and a 3.0 checkout)
b) because the 2to3 sources contain a few files that don't really
   "belong" into the trunk (although a place for them could probably
   be found), such as find_pattern utility.
c) to continue allowing stand-alone releases; IIUC, Collin Winter
   wants to change this package into a general Python rewriting
   library, which might be useful even in a 2.5 context.

I don't think there can be much said about the layout of the repository:
the top-level directory contains various projects (including python),
and sandbox contains "stuff".

Within the Python tree, there are really not that many exceptions
to the rule "trunk is where all new features go", apart from the 3k
branch, of course. One class of exceptions is libraries that need
to stay backwards compatible, see PEP 291. The other class of
exceptions is libraries whose official sources are outside trunk,
namely (possibly incomplete):
- lib2to3
- xml.etree, and Modules/_elementtree.c
- bsddb (recently)
- _multiprocessing ???
- Modules/zlib
Those have special commit constraints, and the maintainer should be
contacted if you don't know what the constraints are. A few other
packages are also separately released but don't have such constraints:
- ctypes
- sqlite
For these packages, the maintainers will pickup and changes
themselves and merge them into whatever external repository they
may use.

Regards,
Martin


More information about the Python-checkins mailing list