[Python-3000] Py3k release schedule worries (original) (raw)

Guido van Rossum guido at python.org
Thu Dec 21 21:59:11 CET 2006

On 12/20/06, Brett Cannon <brett at python.org> wrote:

On 12/18/06, Guido van Rossum <guido at python.org> wrote: > Ok, so be it. Let this be a pronouncement -- the only stdlib reorg > we're doing will be (a) deleting silly old stuff; (b) rename modules > that don't conform to the current module/package naming convention, > like StringIO, cPickle or UserDict.

Care to give a more concrete rule on (a)? For instance, is the AL/al modules worth keeping around, or any of the IRIX modules? What about modules that still lack documentation? How about modules that have not been updated since a certain version like 1.5.2 or a certain amount of time (like 3 or 4 years)?

No, I don't want to give a blanket rule. Come up with a list of modules and reasons why they should be deleted and I'll review it.

I just want to get a rough idea so that a separate thread can be started to discuss modules that should go. We can do svn log checks on code and documentation to try to automatically find out what modules have no love. We can also do Google Code Search queries on import statements to see how much various modules are used.

I don't think this is something that needs to be automated. It needs actual thought.

As for (b), does this also extend to modules within a package? For instance, wsgi.simpleserver or a bunch of the distutils submodules have underscores in them and PEP 8 says underscores are bad for modules and packages. Similar issue goes for xml.etree.ElementTree. But there is no mention in the PEP about modules within a package.

The email package renamed all its internal modules to conform. But since the packages you mention here are owned by external contributors, this should be negotiated on a case-by-case basis. I personally find ElementTree.py a worse offender than simple_server.py (and I'm not sure I still agree 100% with the rule against underscores).

-- --Guido van Rossum (home page: http://www.python.org/~guido/)

More information about the Python-3000 mailing list