[Python-3000] PEP 3108: Standard Library Reorganization

Brett Cannon brett at python.org
Wed Jan 3 22:07:22 CET 2007


On 1/3/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
> On 2 Jan, 2007, at 1:14, Brett Cannon wrote:
>
>
> >
> > * buildtools
> >    2.3
>
> This one is still used by buildapplet (a mac specific tool/module).
> However, see below for more on this.


Since the deprecation has already occurred it's out of my hands.

> * cfmfile
> >    2.4
>
> mac specific, I don't know if this works on OSX (Jack probably knows).


It's already deprecated so I am not going to worry about it.

> * macfs
> >    2.3
>
> Mac specific, I have no idea whether this is still in use.


Same as above.

> * Mac
> >    + applesingle
> >        - Undocumented.
> >            * AppleSingle is a binary file format for A/UX.
> >                + A/UX no longer distributed.
>
> No problems here.


Yay, no argument!  =)

> * UNIX
> >    + nis
> >        - Wrapper for NIS.
> >            * NIS has been replaced by LDAP, DNS, and Kerberos.
>
> That's rather optimistic, NIS is still in active use. NIS is often
> easier to setup than LDAP/Kerberos, especially with older proprietary
> unix versions.


It's already been saved.

> * telnetlib
> >    + Telnet is not used very much anymore.
> >        - Telnet is unsafe.
> >        - Most people use SSH instead.
>
> I still use telnet to connect to embedded systems, or even ancient
> unix systems.  I must admit that I don't often use the telnetlib
> module but mostly just use plain socket connections and ignore the
> telnet protocol.


The module has been saved.

> * asynchat/asyncore
> >    + Third-party libraries provide better solutions.
> >        - twisted [#twisted]_
> >    + Deprecation previously supported [#py-dev-summary-2004-11-01]_
>
> Asyncore is still in active use, also not everyone agrees that
> Twisted is better.


Been saved.

> Modules to Rename
> > =================
> >
> >
> > PEP 8 specifies that modules "should have short, lowercase names,
> > without underscores" [#pep-0008]_.
>
> Why does the restriction on underscores exist? Removing that
> restriction would make lowercase-only names easier to use
> (basehttpserver vs. base_http_server).


I think Guido said he preferred it that way.

> * autoGIL
> >    autogil
>
> This one is mac specific. It's probably possible to completely drop
> this one with some changes to  the Carbon bindings.


So should this be deprecated to force the change, or leave it be for now?

> * Carbon
> >    carbon
>
> Also mac specific. I'm pretty sure the capitalization is on purpose,
> this is a wrapper for Apple's Carbon libraries.


Possibly, but it still breaks the rules.

> * EasyDialogs
> >    easydialogs
> > * FrameWork
> >    framework
>
> Also mac specific. Framework is badly documented and hasn't even been
> updated to support Carbon Events, which itself is ancient technology
> by now.


So FrameWork can go?

> * MacOS
> >    macos
>
> > * MiniAEFrame
> >    miniaeframe
>
> Mac specific.
>
> > * Nav
> >    nav
>
> Mac specific.
>
> > * PixMapWrapper
> >    pixmapwrapper
>
> Mac specific
>
> > * W
> >    w
>
> Mac specific and ancient (see Framework). It's also no longer present
> in the trunk.


Then why are there still docs for it?

>
> >
> > Merging C and Python implementations of the same interface
> > ----------------------------------------------------------
> >
> > Several interfaces have both a Python and C implementation.  While it
> > is great to have a C implementation for speed with a Python
> > implementation as fallback, there is no need to expose the two
> > implementations independently in the stdlib.  For Python 3.0 all
> > interfaces with two implementations will be merged into a single
> > public interface.
>
> +lots on that. A Python and C implementation that are almost but not
> quite the same can be confusing at times.
>
>
> > Open Issues
> > ===========
> > * mac
> >    + Various Mac-specific modules.
> >    + Same can be done for other platform-specific code.
>
> The mac libraries need some serious love. Most of the extensions and
> corresponding python libraries are generated from Apple's headers
> files, but generating them requires the old OS9 SDK. It should be
> possible to convert the toolchain to use the current OSX headers, but
> that requires someone that either knows how bgen works or is willing
> to spend time to learn bgen.


Does that means we should remove all of the bgen-based modules (is that all
of them)?

Several parts of the mac library should be deprecated in 2.6 and
> removed in 3.0. Applescript/OSA support is an example of that: the
> applescript support in the stdlib is awkward to use and has some bugs
> (especially on intel macs).


Library references says gensuitemodule, aetools, aepack, aetypes, and
MiniAEFrame are for OSA.  Should they all go?

There's also a much better way to
> interface with Applescript/OSA: appscript (http://
> appscript.sourceforge.net/).


Are you up to helping me figure out what Mac modules should go?  If I write
up a list Mac-specific modules can you tell me which ones should go?

Support for CoreFoundation should also be dropped, Carbon.CF is
> incomplete and barely tested. I'm already working on extending PyObjC
> to include full support for CoreFoundation (and other frameworks
> based on CF) [http://pyobjc.sf.net].


That's good to hear.

>
> > Modules reliant on obsolete/rarely used file formats?
> > -----------------------------------------------------
> >
> > Several modules in the stdlib work on a specific file format.  It is
> > possible some of these formats are no longer used and thus the stdlib
> > modules for them can go.  Below is a list of some modules which rely
> > on a file format that may be obsolete.
> >
> > * aifc
> >    AIFF and AIFF-C audio files.  Appears to be only user of the cl
> >    module (which is undocumented).
>
> AIFF is not an obsolete file format (http://en.wikipedia.org/wiki/AIFF).


OK.

> * binhex
> >    binhex4 encoding.
>
> binhex is still used in the mac world, although most software seems
> to move to more cross-platform-friendly formats.



I have not come across a binhex file on OS X in ages (everything seems to be
DMG these days).  Is the use in the MacPython world enough to warrant
keeping this?

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


More information about the Python-3000 mailing list