[Python-Dev] Module renaming and pickle mechanisms

[Brett Cannon]

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.

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

Yeah, yeah. One thing at a time.

-Brett