[Python-Dev] Module renaming and pickle mechanisms

Benjamin Peterson musiccomposition at gmail.com
Tue May 20 00:26:17 CEST 2008


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 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.


<shameless_advertising>Bazaar can handle renames
correctly.</shameless_advertising>


-- 
Cheers,
Benjamin Peterson
"There's no place like 127.0.0.1."


More information about the Python-Dev mailing list