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

[Raymond Hettinger]

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.


Raymond