[Python-3000] PEP 3108: Standard Library Reorganization

[Ronald Oussoren]

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.

> * cfmfile
>    2.4

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

> * macfs
>    2.3

Mac specific, I have no idea whether this is still in use.

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

No problems here.

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

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

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


> * autoGIL
>    autogil

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

> * Carbon
>    carbon

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

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

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


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

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). There's also a much better way to  
interface with Applescript/OSA: appscript (http:// 
appscript.sourceforge.net/).

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

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

> * binhex
>    binhex4 encoding.

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

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3562 bytes
Desc: not available
Url : http://mail.python.org/pipermail/python-3000/attachments/20070103/d628ead7/attachment-0001.bin