[Python-3000] PEP 3108: Standard Library Reorganization
Brett Cannon
brett at python.org
Wed Jan 3 22:58:39 CET 2007
On 1/3/07, Ronald Oussoren <ronaldoussoren at mac.com> wrote:
>
>
> On 3 Jan, 2007, at 22:07, Brett Cannon wrote:
>
>
>
> 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.
>
>
> Let me rephrase: buildtools shouldn't be removed in 2.6 as it is still in
> use by buildapplet which isn't deprecated. I wasn't paying much attention
> to python-dev when 2.3 was released and hadn't noticed that buildtools is
> deprecated or I'd warned about this earlier.
>
This is PEP is for 3.0, not 2.6. And it looks like it is only a documented
deprecation, not in PEP 4, so taking it back is no big deal. Just change
the docs (same with the other Mac-specific deprecations). If you can file a
bug report to remove the deprecations that you want to keep around.
> * 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.
>
>
> So what, rule's are there to be broken :-). IMHO there should be room for
> deviations from PEP8 when there are good reasons to do so.
>
Well, there is also talk of putting platform-specific stuff in their own
package and that would help make it easier to ignore. =)
> * 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?
>
>
> I think so.
>
OK, added.
> * 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?
>
>
> I don't know. To be honest I didn't even know there were docs for it.
>
OK. File a bug report to have the docs pulled if the thing is not even in
Python anymore.
>
> > >
> > > 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)?
>
>
> No that means that someone should look at bgen to make it use the current
> version of the headers. The generated code still works, but doesn't expose
> functionality that was added after MacOS9.
>
Ah, OK.
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?
>
>
> aetools, aepack and aetypes should definitely go. The code in those
> modules has serious byteorder related issues: the code is heavily dependend
> on the fact that Mac's use a bigendian processor and that is no longer
> true.
>
> The others should also go in python 3.0.
>
OK I added aetools, aepack, aetypes, and MiniAEFrame to the list of things
to 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?
>
>
> Yes, but not right now. I'm trying to hunt down a rather nasty bug in
> PyObjC. Threading sucks, even if you can rely on the GIL in your C code :-(
>
Good enough. No rush. I will pull together the list and send it to you
off-list (with a cc to Bob).
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.
>
>
>
>
> > * 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?
>
>
> I'm not happy about dropping modules when there are no alternatives. Some
> email clients, such as Eudora can still send attachments in binhex format
> (although not by default).
>
> I know that some companies still use OS9 systems and binhex is used more
> in those environments.
>
> BTW. I'm just -0 on removing binhex. Thanks to setuptools and PyPI it's
> easy enough to move binhex to a separate distribution when it turns out that
> people still use it.
>
Well, based on that info binhex can stay.
-Brett
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.python.org/pipermail/python-3000/attachments/20070103/f91dc8b9/attachment.html
More information about the Python-3000
mailing list