[Python-Dev] Module renaming and pickle mechanisms (original) (raw)

Brett Cannon brett at python.org
Tue May 20 00:57:17 CEST 2008

On Mon, May 19, 2008 at 3:26 PM, Benjamin Peterson <musiccomposition at gmail.com> wrote:

On Mon, May 19, 2008 at 7:08 AM, M.-A. Lemburg <mal at egenix.com> wrote:

On 2008-05-18 22:24, Brett Cannon wrote:

On Sun, May 18, 2008 at 6:14 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:

M.-A. Lemburg wrote:

Perhaps I have a misunderstanding of the reasoning behind doing the renaming in the 2.x branch, but it appears that the only reason is to get used to the new names. That's a rather low priority argument in comparison to the breakage the renaming will cause in the 2.x branch. I think this is the key point here. The possibility of breaking pickling compatibility never came up during the PEP 3108 discussions, so wasn't taken into account in deciding whether or not backporting the name changes was a good idea. I think it's pretty clear that the code needs to be moved back into the modules with the old names for 2.6. The only question is whether or not we put any effort into making the new stdlib organisation usable in 2.x, or just rely on 2to3 to fix it (note that the "increasing the common subset" argument doesn't really apply, since you can catch the import errors in order to try both names). Problem with this is it makes forward-porting revisions to 3.0 a PITA. By keeping the module names consistent between the versions merging a revision is just a matter of svnmerge merge with the usual 3.0-specific changes. Reverting the modules back to the old name will make forward-porting much more difficult as I don't think svn keeps rename information around (and thus map the old name to the new name in terms of diffs). svnmerge is written in Python, so wouldn't it be possible to add support for maintaining such renaming to that tool ? svnmerge.py is mostly a wrapper over svn merge, and svn merge can't handle it, so I don't think is easily possible.

I think MAL was suggesting add some property that kept track of skipped merges or something.

I don't think that an administrative problem such as forward- porting patches to 3.x warrants breakage in the 2.x branch. I am a bit worried for the sanity of the Merger, though. Merges into non-existent files are skipped automatically, so it doesn't make life any easier.

It will either have to be done in 2.6 and the immediately forward-ported or done in 3.0 and backported. I will follow the latter IF I feel like bothering with the backport.

Bazaar can handle renames correctly.

Yeah, yeah. One thing at a time.

-Brett

More information about the Python-Dev mailing list