[stdlib-sig] Changing the 2.6 renames to not break pickle

[Brett Cannon]

On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger <python at rcn.com> wrote:
> From: "Brett Cannon" <brett at python.org>
>>>>
>>>> So, here is my idea (only need to care about modules that have stuff
>>>> to pickle, e.g., don't need to change test.support):
>>>>
>>>> * Rename lib-old to lib-new
>>>>
>>>> * Change the names in lib-new to the new names.
>>>>
>>>> * Change the names in the stdlib to the old names.
>>>>
>>>> * Move the Py3K warnings out of the stubs in lib-new and put them in
>>>> the modules directly stored in the stdlib.
>
> I thought we weren't going to put in 3k warnings for anything
> that was automatically handled by the 2-to-3 converter.
> I remember taking out a few of those warnings at some point
> once the converter had been brought up-to-date.
>
> IIRC, the reason is that it makes the -3 option more difficult to use
> in that it would give you tons of warnings for things you don't need
> to change to get programs working after the 2-to-3 conversion.
>
> The transition was supposed to be:
> 1. get unittests working in 2.6
> 2. run 2.6 with the -3 option and do fixups which leave the code running in
> 2.6 and unittests still passing.
> 2. run the 2-to-3 converter and verify the unittests still work.
>
> Step two is the only manual step and we want to minimize the number of
> manual interventions.
>
>>>>
>>>> * Change the imports in the stubs in lib-new to import the old name
>>>> and suppress the Py3K warning (probably use
>>>> test.support.catch_warning() with a *very* specific ignore filter).
>>>
>>> That plan seems harmless enough, but why bother?
>>
>> Same reason given on python-dev when you asked this question before.
>> =) 2.6 is supposed to minimize the differences between 2.x and 3.0 as
>> much as possible without having to run 2to3.
>
> Put me down for a -1.  ISTM, this does more harm than good.
> Nothing good can come from conflating the old and new names in the same code
> base.
> It doesn't make life easier for people learning 2.6, nor for people
> converting from 2.6,
> and especially not for people who already have modules with conflicting
> names (it's not
> have to imagine that some users or third-party apps have a module named
> queue).
>
>> Plus I don't want to have
>> to change imports in patches between 2.6 and 3.0 if I don't have to.
>
> Won't you still have to import libnew, so the effort will be about the same?
>
> It has been said many times that the goal is not have the exact same code
> run
> under both 2.6 and 3.0.  I'm not sure how this is notion is rearing its head
> again.
>

You know what, we will just do it your way without the new names in
2.6 because my stress level just can't take being bothered with adding
new stubs. We will just revert the patches that applied the new names
in 2.6 and be done with it.

-Brett