stdlib-sig May 2008

stdlib-sig@python.org

9 participants
5 discussions

Changing the 2.6 renames to not break pickle
by Brett Cannon 20 May '08

20 May '08

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

4 8

Re: [stdlib-sig] Changing the 2.6 renames to not break pickle
by Antoine Pitrou 19 May '08

19 May '08

Le lundi 19 mai 2008 à 13:20 -0700, Brett Cannon a écrit : > On Mon, May 19, 2008 at 12:48 PM, Antoine Pitrou <solipsis(a)pitrou.net> wrote: > > Le lundi 19 mai 2008 à 12:21 -0700, Brett Cannon a écrit : > >> 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? > > > > Are 2.x pickles supposed to be re-usable under py3k? > > No. This is only so that 2.5 pickles work with 2.6. Ok. But still, it means that help(new_module_name) will display the old module name in the help contents?

2 1

gestalt, too?
by Benjamin Peterson 16 May '08

16 May '08

I don't see gestalt on PEP 3108, but it is a Mac module. -- Cheers, Benjamin Peterson "There's no place like 127.0.0.1."

5 22

Removing the deprecated sre module?
by Alexandre Vassalotti 07 May '08

07 May '08

Hi, I know that the deadline for module removal is now passed, but I think we forgot to decide what should happen to the deprecated sre module: >>> import sre :1: DeprecationWarning: The sre module is deprecated, please import re. >>> help(sre) ... DESCRIPTION This file is only retained for backwards compatibility. It will be removed in the future. sre was moved to re in version 2.5. ... Currently, the sre module is just a stub that imports the re module. So, I don't think removing in Py3k will cause any problem. Cheers, -- Alexandre

4 7

Getting simplejson 1.9 into the stdlib
by Brett Cannon 05 May '08

05 May '08

http://bugs.python.org/issue2750 holds the issue to get simplejson 1.9 into the stdlib as the new 'json' module. I am going to give this SIG a week to go through the code and such before I announce on python-dev. The todo list is: * Get it building in the core. * Make sure the tests are good and run without issue. * Convert the docs (the docstrings are already in reST, so it should mostly be a copy-and-paste job with some added markup). * Verify the code is PEP 7/PEP 8 compatible. * Convert to 3.0. The build and test steps are the most critical as the rest can occur in parallel once the code is in svn. People who want to claim a step just update the issue. -Brett

2 2

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

stdlib-sig May 2008