[Python-3000] Py3k release schedule worries

[Guido van Rossum]

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.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/)