[Python-3000] PEP 3108: Standard Library Reorganization

[Josiah Carlson]

"Brett Cannon" <brett at python.org> wrote:
> On 1/1/07, Josiah Carlson <jcarlson at uci.edu> wrote:
> > "Brett Cannon" <brett at python.org> wrote:
> > * telnetlib
> > >     + Telnet is not used very much anymore.
> > >         - Telnet is unsafe.
> > >         - Most people use SSH instead.
> >
> > I don't know how common telnet lib use is currently, but I have found it
> > useful in writing plaintext line-based clients (like SMTP, POP, HTTP,
> > IMAP, etc.), before moving on to writing async* derived clients.
> 
> Fair enough.  If more people step up it can stay.
> 
> > * base64/quopri/uu
> > >     + Support exists in the codecs module.
> > >     + If removed (along with binhex), also remove binascii.
> > >         - C implementation of base64, binhex, and uu modules.
> >
> > The binascii module has become a catch all module for various plaintext
> > <-> binary conversions.
> 
> 
> Right, but is it necessarily the best thing that it has become a catch-all?

I would guess that Raymond Hettinger would have something to say about
this (being that he was going to add the long/int <-> binary conversion
to binascii). I don't know if he has been paying attention and/or
reading py3k.


> > * asynchat/asyncore
> > >     + Third-party libraries provide better solutions.
> > >         - twisted [#twisted]_
> > >     + Deprecation previously supported [#py-dev-summary-2004-11-01]_
> >
> > There is quite a bit of user code that depends on asynchat/asyncore
> > modules.  While there are many people who end up using twisted, forcing
> > all asynchronous socket users to "drink the twisted kool-aid" would set
> > a bad precident for any commonly used stdlib Python library with a more
> > fully-featured 3rd party module.
> 
> Well, I just remember the thread that led to the suggestion the two modules
> go.  It can be saved from the chopping block but I remember part of the
> issue was no one was wanting to maintain the modules anymore and they were
> starting to collect dust.

Removing asynchat/asyncore would also necessitate removing smtpd, which
is a subclass of asynchat.async_chat .

Dennis Allison offers the following in that thread,

    It might be worthwhile to list what the existing problems are with
    the asyncore and asynchat libraries.  There is also the problem that
    many applications, Zope among them, depend upon them.

http://mail.python.org/pipermail/python-dev/2004-November/049832.html

A later post points off to the Zope mailing list for reasons why
asyncore/asynchat are a problem, but Martin points out that he doesn't
see any "problems" specified by the poster as applicable.

http://mail.python.org/pipermail/python-dev/2004-November/049834.html

Guido states,

    IMO (after having worked with it extensively in ZEO/zrpc) asyncore
    is a really small piece of functionality that you'll need no matter
    how you slice it, if you don't want to do all your I/O synchronously
    (which would mean one thread per connection).

http://mail.zope.org/pipermail/zope3-dev/2002-October/003232.html

If Martin and Guido think that asyncore is fine, and one would need to
completely switch paradigms to use the only alternate, then it really
doesn't make sense to remove it.


If asyncore/asynchat/smtpd needs a maintainer, then I volunteer.  Assign
all bugs, patches, etc., to me and I'll handle them.


> > * stat
> > >     + ``os.stat`` now returns a tuple with attributes.
> >
> > The stat module also offers useful functions like stat.IS_DIR() for
> > determining if an object is a directory.
> 
> 
> Perhaps the functions should move to os or be part of the object returned by
> os.stat.

Methods sound better (to me) than functions in the os module.  If for
the reason that os.stat(fn).ST_ISDIR() would be easier to remember than
os.ST_ISDIR(os.stat(fn).st_mode) .

> > * SocketServer
> > >     socketserver
> >
> > SocketServer and its derivatives (*HTTPServer) are tricky (I've been
> > seeing them used quite a bit)...
> 
> 
> Well, I am not proposing to remove them although I would not cry if the
> HTTPServer children disappeared, but that's just me.  We will have to see if
> anyone else is up for letting them go.

I'm not voting for their removal, just stating that they are trickly to
handle, both in a naming, and in an understanding perspective.  Honestly,
which is easier to read and/or understand to you: basehttpserver or
BaseHTTPServer?  I prefer CamelCase.


> > * Servers
> > >     + BaseHTTPServer
> > >     + CGIHTTPServer
> > >     + DocXMLRPCServer
> > >     + SimpleHTTPServer
> > >     + SimpleXMLRPCServer
> > >     + SocketServer
> >
> > Would it be a reasonable semantic to say that 'no top level modules or
> > packages can violate PEP 8 module/package naming guidelines', but
> > sub-modules or packages may use CamelCase by historical precident or
> > when doing so would make understanding the purpose of the module/package
> > easier?
> 
> Could.  The renaming as of right now only enforces it on the package name
> stringently.  But the style guide is not my call.

xml.etree.ElementTree could be used as an example of what could/should
or shouldn't be done.

 - Josiah