[Python-3000] PEP 3108: Standard Library Reorganization

[Brett Cannon]

On 1/1/07, Josiah Carlson <jcarlson at uci.edu> wrote:
>
>
> "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.


Raymond might, but I don't think he is following Py3K.  But MAL kicked the
PEP over to python-dev so he might notice now.

Are you at least okay with base64, quopri, and uu going?  You are just
arguing for the saving of binascii, right?

Does anyone else care to try to save binascii?

> > * 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.


That's good enough for me.  They are saved.

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


I have added the requirement for the removal of the stat module.  And
obviously the names will need some work.

> > * 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.


Perhaps, but consistency is more important (at least to me).  Best bet would
be to put them in a package.

> > * 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.


It is its own special open issue for that reason.  =)  I personally would
prefer they go into a package, we ditch the CamelCase and move to
underscores for them.

-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070102/d9474830/attachment.html