[Python-3000] PEP 3108: Standard Library Reorganization

Jim Jewett jimjjewett at gmail.com
Tue Jan 2 23:45:02 CET 2007


On 1/1/07, Brett Cannon <brett at python.org> wrote:
> =================
>
> Previously deprecated
> ---------------------
>
> Modules in this section have been deprecated at some point in the
> Python 2.x release series but are currently still distributed with
> Python

    (though not on all platforms).

> Minimal usage
> -------------
>
> Some modules that are platform-independent have minimal usage.  This
> can be from how easy it is to implement the functionality from scratch
> or because the audience for the code is small.

> * imputil

Assuming your import rewrite happens, then yes, all the legacy import
modules should be removed. :D

> * telnetlib
>     + Telnet is not used very much anymore.
>         - Telnet is unsafe.
>         - Most people use SSH instead.

I still use telnet.  I don't typically script it, but if I need to
script a network connection other than http, that is where I start.

I also note that SSH isn't available by default on windows (or some
unix builds), nor is there a stdlib wrapper for it.

> * asynchat/asyncore
>     + Third-party libraries provide better solutions.
>         - twisted [#twisted]_

Too much kool-aid.

"Everyone" sort of agrees that there are problems with the existing
libraries, but not on precisely what those problems are, let alone
what the solution should look like.  Some of the "this is obvious"
patches were rejected as breaking something for someone else.

> * getopt
>     + optparse provides better functionality.

Yes and no.  getopt does provide a (non-python-specific) standard
parsing, and is still widely used.

I would say keep it unless the converter could automate the
translation to *lightweigt* optparse usage.  (Shouldn't add more than
~15% to the script's "here is where I deal with options" code.)

> Modules to Rename
> =================

> PEP 8 violations
>  ----------------

> PEP 8 specifies that modules "should have short, lowercase names,
> without underscores" [#pep-0008]_.  There is no mention, though, if
> this rule extends to modules contained within a package.  The
> assumption is that underscores are acceptable in module names when
> they are contained within a package but that any uppercase letters is
> not.

PEP 8 should be clarified before this is implemented.

> * autoGIL
>     autogil
> * Carbon
>     carbon
> * ColorPicker
>     colorpicker
> * EasyDialogs
>     easydialogs
> * FrameWork
>     framework
> * MacOS
>     macos
> * MiniAEFrame
>     miniaeframe
> * Nav
>     nav
> * PixMapWrapper
>     pixmapwrapper
> * W
>     w

It would be best to rename these to indicate that they are
mac-specific.  (Well, that or include pure-python or Tk
implementations on other platforms.  There are already 3rd-party ports
for some.)  Some of them seem like the obvious answer for certain
problems, but then either the code isn't cross-platform (if you're
using a Mac) or the module doesn't exist (which makes you wonder if
you installed correctly).

Something as simple as mac.colorpicker, easydialogs, mac.nav, ...
would have been helpful.

I suppose the same question would apply to _winreg, and to any
not-mentioned platform-specific modules, but in practice, I seem to
have the most frustration with Mac-only modules, even though there
seem to be more Linux-only developers.

-jJ


More information about the Python-3000 mailing list