On 12/20/06, Brett Cannon <[EMAIL PROTECTED]> wrote: > On 12/18/06, Guido van Rossum <[EMAIL PROTECTED]> 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.simple_server 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/) _______________________________________________ Python-3000 mailing list [email protected] http://mail.python.org/mailman/listinfo/python-3000 Unsubscribe: http://mail.python.org/mailman/options/python-3000/archive%40mail-archive.com
