<br><br><div><span class="gmail_quote">On 1/3/07, <b class="gmail_sendername">Ronald Oussoren</b> <<a href="mailto:ronaldoussoren@mac.com">ronaldoussoren@mac.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<br>On 2 Jan, 2007, at 1:14, Brett Cannon wrote:<br><br><br>><br>> * buildtools<br>> 2.3<br><br>This one is still used by buildapplet (a mac specific tool/module).<br>However, see below for more on this.</blockquote>
<div><br>Since the deprecation has already occurred it's out of my hands. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * cfmfile<br>> 2.4<br><br>mac specific, I don't know if this works on OSX (Jack probably knows).</blockquote><div><br>It's already deprecated so I am not going to worry about it.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * macfs<br>> 2.3<br><br>Mac specific, I have no idea whether this is still in use.</blockquote><div><br>Same as above. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * Mac<br>> + applesingle<br>> - Undocumented.<br>> * AppleSingle is a binary file format for A/UX.<br>> + A/UX no longer distributed.<br><br>No problems here.</blockquote>
<div><br>Yay, no argument! =)<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * UNIX<br>> + nis<br>> - Wrapper for NIS.
<br>> * NIS has been replaced by LDAP, DNS, and Kerberos.<br><br>That's rather optimistic, NIS is still in active use. NIS is often<br>easier to setup than LDAP/Kerberos, especially with older proprietary
<br>unix versions.</blockquote><div><br>It's already been saved.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * telnetlib
<br>> + Telnet is not used very much anymore.<br>> - Telnet is unsafe.<br>> - Most people use SSH instead.<br><br>I still use telnet to connect to embedded systems, or even ancient<br>unix systems. I must admit that I don't often use the telnetlib
<br>module but mostly just use plain socket connections and ignore the<br>telnet protocol.</blockquote><div><br>The module has been saved.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * asynchat/asyncore<br>> + Third-party libraries provide better solutions.<br>> - twisted [#twisted]_<br>> + Deprecation previously supported [#py-dev-summary-2004-11-01]_<br><br>Asyncore is still in active use, also not everyone agrees that
<br>Twisted is better.</blockquote><div><br>Been saved. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> Modules to Rename
<br>> =================<br>><br>><br>> PEP 8 specifies that modules "should have short, lowercase names,<br>> without underscores" [#pep-0008]_.<br><br>Why does the restriction on underscores exist? Removing that
<br>restriction would make lowercase-only names easier to use<br>(basehttpserver vs. base_http_server).</blockquote><div><br>I think Guido said he preferred it that way. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * autoGIL<br>> autogil<br><br>This one is mac specific. It's probably possible to completely drop<br>this one with some changes to the Carbon bindings.</blockquote><div><br>So should this be deprecated to force the change, or leave it be for now?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * Carbon<br>> carbon<br><br>Also mac specific. I'm pretty sure the capitalization is on purpose,
<br>this is a wrapper for Apple's Carbon libraries.</blockquote><div><br>Possibly, but it still breaks the rules.<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * EasyDialogs<br>> easydialogs<br>> * FrameWork<br>> framework<br><br>Also mac specific. Framework is badly documented and hasn't even been<br>updated to support Carbon Events, which itself is ancient technology
<br>by now.</blockquote><div><br>So FrameWork can go? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">> * MacOS<br>> macos
<br><br>> * MiniAEFrame<br>> miniaeframe<br><br>Mac specific.<br><br>> * Nav<br>> nav<br><br>Mac specific.<br><br>> * PixMapWrapper<br>> pixmapwrapper<br><br>Mac specific<br><br>> * W<br>> w
<br><br>Mac specific and ancient (see Framework). It's also no longer present<br>in the trunk.</blockquote><div><br>Then why are there still docs for it? <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>><br>> Merging C and Python implementations of the same interface<br>> ----------------------------------------------------------<br>><br>> Several interfaces have both a Python and C implementation. While it
<br>> is great to have a C implementation for speed with a Python<br>> implementation as fallback, there is no need to expose the two<br>> implementations independently in the stdlib. For Python 3.0 all<br>> interfaces with two implementations will be merged into a single
<br>> public interface.<br><br>+lots on that. A Python and C implementation that are almost but not<br>quite the same can be confusing at times.<br><br><br>> Open Issues<br>> ===========<br>> * mac<br>> + Various Mac-specific modules.
<br>> + Same can be done for other platform-specific code.<br><br>The mac libraries need some serious love. Most of the extensions and<br>corresponding python libraries are generated from Apple's headers<br>files, but generating them requires the old OS9 SDK. It should be
<br>possible to convert the toolchain to use the current OSX headers, but<br>that requires someone that either knows how bgen works or is willing<br>to spend time to learn bgen.</blockquote><div><br>Does that means we should remove all of the bgen-based modules (is that all of them)?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Several parts of the mac library should be deprecated in 2.6 and<br>removed in
3.0. Applescript/OSA support is an example of that: the<br>applescript support in the stdlib is awkward to use and has some bugs<br>(especially on intel macs). </blockquote><div><br>Library references says gensuitemodule, aetools, aepack, aetypes, and MiniAEFrame are for OSA. Should they all go?
</div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">There's also a much better way to<br>interface with Applescript/OSA: appscript (http://
<br><a href="http://appscript.sourceforge.net/">appscript.sourceforge.net/</a>).</blockquote><div><br>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?
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Support for CoreFoundation should also be dropped, Carbon.CF is<br>incomplete and barely tested. I'm already working on extending PyObjC
<br>to include full support for CoreFoundation (and other frameworks<br>based on CF) [<a href="http://pyobjc.sf.net">http://pyobjc.sf.net</a>].</blockquote><div><br>That's good to hear. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>> Modules reliant on obsolete/rarely used file formats?<br>> -----------------------------------------------------<br>><br>> Several modules in the stdlib work on a specific file format. It is<br>> possible some of these formats are no longer used and thus the stdlib
<br>> modules for them can go. Below is a list of some modules which rely<br>> on a file format that may be obsolete.<br>><br>> * aifc<br>> AIFF and AIFF-C audio files. Appears to be only user of the cl
<br>> module (which is undocumented).<br><br>AIFF is not an obsolete file format (<a href="http://en.wikipedia.org/wiki/AIFF">http://en.wikipedia.org/wiki/AIFF</a>).</blockquote><div><br>OK. <br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
> * binhex<br>> binhex4 encoding.<br><br>binhex is still used in the mac world, although most software seems<br>to move to more cross-platform-friendly formats.</blockquote><div><br><br>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?
<br><br>-Brett<br></div></div>