[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:
> > * fileinput
> >     + Basic functionality handled by ``itertools.chain``.
> >     + Using ``enumerate`` (for the line number in the file),
> >       ``itertools.repeat`` (for returning the filename with each
> >       line), and ``zip`` (for connecting the ``enumerate`` object and
> >       ``itertools.repeat`` object)  provides 95% of other unique
> >       abilities of fileinput.
>
> I agree with Giovanni on the above.


OK.  Starting to sound like fileinput should stay.

> * 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'm not sure if using .encode()/.decode() are
> necessarily desireable, especially in the case of certain binascii
> conversions that involve long/int <-> binary (that didn't make it into
> Python 2.5).


 Anyone else want to weigh in 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.

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

> * thread
> >     + People should use 'threading' instead.
> >         - Rename 'thread' to _thread.
> >         - Deprecate dummy_thread.
> >             * Rename to _mockthread.
> >             * Change of name better reflects modules purpose.
> >     + Guido has previously supported the deprecation
> >       [#thread-deprecation]_.
>
> Sounds good.  Can we get this particular change into the 2.x series?
> I've seen too much code that mixes and matches threading and thread use.


Probably if people want it.

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

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

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