Now that April 15th has past, it's time to start thinking about how best to handle the reorg. I have some ideas on how to make it all work. For 2.6, the modules should be renamed. The old names should be maintained with stub modules that are kept in some directory, such as lib-old. This separate directory is needed since some modules are only changing their case and that will wreak havoc on case-insensitive file systems. There should also be a Python 3.0 warning about the named deprecation. For 3.0, we need a fixer that deals with imports. Using the 'as' keyword to prevent the code from needing to be changed in any way would be best. There are probably some fixers already that deal with import that might be available for tweaking to make it work for this situation. While we wait for Guido to pronounce on the PEP (probably late next week) we can start discussing this and getting stuff lined up. I personally don't know how much time I will have for this (dealing with a relationship ending and having to move because of it) so any and all help I can get for this will be appreciated. -Brett
On Thu, Apr 17, 2008 at 6:40 PM, Brett Cannon <brett@python.org> wrote: > For 2.6, the modules should be renamed. The old names should be > maintained with stub modules that are kept in some directory, such as > lib-old. This separate directory is needed since some modules are only > changing their case and that will wreak havoc on case-insensitive file > systems. There should also be a Python 3.0 warning about the named > deprecation. So, the following the workflow? 1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk) 2. Fix imports in the stdlib and update the docs. 3. Commit and merge into 3.0. 4. (back in trunk) make a file that does a start import (modules with __all__ will require some more work) in lib-old and gives a py3k warning 5. Block that revision > > While we wait for Guido to pronounce on the PEP (probably late next > week) we can start discussing this and getting stuff lined up. I > personally don't know how much time I will have for this (dealing with > a relationship ending and having to move because of it) so any and all > help I can get for this will be appreciated. Your word is my command. :) -- Cheers, Benjamin Peterson
On Thu, Apr 17, 2008 at 6:26 PM, Benjamin Peterson <musiccomposition@gmail.com> wrote: > On Thu, Apr 17, 2008 at 6:40 PM, Brett Cannon <brett@python.org> wrote: > > For 2.6, the modules should be renamed. The old names should be > > maintained with stub modules that are kept in some directory, such as > > lib-old. This separate directory is needed since some modules are only > > changing their case and that will wreak havoc on case-insensitive file > > systems. There should also be a Python 3.0 warning about the named > > deprecation. > So, the following the workflow? > 1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk) I think you meant for that to still lead to a good name. =) > 2. Fix imports in the stdlib and update the docs. > 3. Commit and merge into 3.0. > 4. (back in trunk) make a file that does a start import (modules with > __all__ will require some more work) in lib-old and gives a py3k > warning > 5. Block that revision Sounds about right. -Brett > > > > > While we wait for Guido to pronounce on the PEP (probably late next > > week) we can start discussing this and getting stuff lined up. I > > personally don't know how much time I will have for this (dealing with > > a relationship ending and having to move because of it) so any and all > > help I can get for this will be appreciated. > Your word is my command. :) > > > > -- > Cheers, > Benjamin Peterson >
So, the following the workflow? 1. svn mv Lib/BadOldName.py Lib/badoldname.py (in trunk) 2. Fix imports in the stdlib and update the docs. 3. Commit and merge into 3.0. 4. (back in trunk) make a file that does a start import (modules with __all__ will require some more work) in lib-old and gives a py3k warning 5. Block that revision
6. Make a 2-to-3 converter
On Fri, Apr 18, 2008 at 5:28 PM, Christian Heimes <christian@cheimes.de> wrote:
Raymond Hettinger schrieb:
6. Make a 2-to-3 converter
We don't need a new 2to3 fixer for every case. We need some generic fixers that can handle all possible cases. Yep. It *looks* like you can just add it to fix_imports.py.
Christian
-- Cheers, Benjamin Peterson
participants (4)
-
Benjamin Peterson -
Brett Cannon -
Christian Heimes -
Raymond Hettinger