[Python-3000] Py3k release schedule worries
brett at python.org
Fri Dec 22 00:34:38 CET 2006
On 12/21/06, Guido van Rossum <guido at python.org> wrote:
> 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.
OK, I will come up with an initial list and start a thread where
people can either throw a fit or add to 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
More information about the Python-3000