Apparently pickle doesn't like the way renames have been handled in 2.6 and people don't want to mess with pickle, so that means the renames need to change.
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.
* 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).
I think that gets __module__ set to the old module name even when code is imported with the new name. It should also allow the Py3K warnings to stick around without causing issues when importing from the new name or suppressing other Py3K warnings. What do people think?
-Brett
On Mon, May 19, 2008 at 3:21 PM, Brett Cannon brett@python.org wrote:
Apparently pickle doesn't like the way renames have been handled in 2.6 and people don't want to mess with pickle, so that means the renames need to change.
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.
- 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).
I think that gets __module__ set to the old module name even when code is imported with the new name. It should also allow the Py3K warnings to stick around without causing issues when importing from the new name or suppressing other Py3K warnings. What do people think?
Sound fine to me. Although this is going to be mess, it seems to be our only reasonable choice.
-- Alexandre
On Mon, May 19, 2008 at 2:23 PM, Alexandre Vassalotti alexandre@peadrop.com wrote:
On Mon, May 19, 2008 at 3:21 PM, Brett Cannon brett@python.org wrote:
Apparently pickle doesn't like the way renames have been handled in 2.6 and people don't want to mess with pickle, so that means the renames need to change.
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.
- 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).
I think that gets __module__ set to the old module name even when code is imported with the new name. It should also allow the Py3K warnings to stick around without causing issues when importing from the new name or suppressing other Py3K warnings. What do people think?
Sound fine to me. Although this is going to be mess, it seems to be our only reasonable choice.
Yes, it will be a pain. I have not exactly been in high spirits since this came up. But we can move each module on its own so at least it does not need to be done en-masse.
-Brett
From: "Brett Cannon" brett@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.
- 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?
I think that gets __module__ set to the old module name even when code is imported with the new name. It should also allow the Py3K warnings to stick around without causing issues when importing from the new name or suppressing other Py3K warnings. What do people think?
What is the purpose of 2.6 knowing anything about the 3.0 module names? Since this is the kind of thing that the 2-to-3 converter handles easily, how does this make my life any easier when porting programs to 3.0? AFAICT, there is no benefit to me as a programmer, so why bother?
Raymond
On Mon, May 19, 2008 at 5:10 PM, Raymond Hettinger python@rcn.com wrote:
From: "Brett Cannon" brett@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.
- 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. Plus I don't want to have to change imports in patches between 2.6 and 3.0 if I don't have to.
-Brett
From: "Brett Cannon" brett@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
On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger python@rcn.com wrote:
From: "Brett Cannon" brett@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:
- get unittests working in 2.6
- 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
On 2008-05-20 05:40, Brett Cannon wrote:
On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger python@rcn.com wrote:
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.
Sorry, Brett for the wasted time and thank you for reverting the changes.
I'm sure that a lot of Python 2.6 users will make this happy (even if most will probably never know).
On Tue, May 20, 2008 at 2:51 AM, M.-A. Lemburg mal@egenix.com wrote:
On 2008-05-20 05:40, Brett Cannon wrote:
On Mon, May 19, 2008 at 5:31 PM, Raymond Hettinger python@rcn.com wrote:
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.
Sorry, Brett for the wasted time and thank you for reverting the changes.
I actually didn't do any of the renames (been focusing on the deprecations); Benjamin, Alexandre, and Georg did most of the rename commits. My stress comes from feeling responsible for the whole process.
I'm sure that a lot of Python 2.6 users will make this happy (even if most will probably never know).
No, they probably will never know. No one every staid this wasn't a thankless job.
-Brett
-
Alexandre Vassalotti -
Brett Cannon -
M.-A. Lemburg -
Raymond Hettinger