<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;">
<div style=""><br><div><span class="q"><div>On 3 Jan, 2007, at 22:07, Brett Cannon wrote:</div><br><blockquote type="cite"><br><br><div><span class="gmail_quote">On 1/3/07, <b class="gmail_sendername">Ronald Oussoren</b> <
<a href="mailto:ronaldoussoren@mac.com" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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></div></blockquote><div><br></div></span>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.</div></div></blockquote><div><br>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.
<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;"><div style=""><div><div><span class="e" id="q_10fe9eaae19c8dcc_3"><blockquote type="cite">
<div><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></div></blockquote><div><br></div></span></div>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.
</div></div></blockquote><div><br>Well, there is also talk of putting platform-specific stuff in their own package and that would help make it easier to ignore. =) <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;">
<div style=""><div><span class="q"><blockquote type="cite"><div><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></div></blockquote><div><br></div></span>I think so.</div></div></blockquote><div><br>OK, added.<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;">
<div style=""><div><span class="q"><blockquote type="cite"><div><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></div></blockquote><div><br></div></span>I don't know. To be honest I didn't even know there were docs for it.
</div></div></blockquote><div><br>OK. File a bug report to have the docs pulled if the thing is not even in Python anymore. <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;">
<div style=""><div><span class="q"><blockquote type="cite"><div><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></div></blockquote><div><br></div></span>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.
</div></div></blockquote><div><br>Ah, 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;"><div style=""><div><span class="q"><blockquote type="cite">
<div><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?
<br></div></div></blockquote><div><br></div></span>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.
</div><div><br></div><div>The others should also go in python 3.0. </div></div></blockquote><div><br><br>OK I added aetools, aepack, aetypes, and MiniAEFrame to the list of things to 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;">
<div style=""><div><span class="q"><blockquote type="cite"><div><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/" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">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></div></blockquote><div><br></div></span>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 :-(
</div></div></blockquote><div><br><br>Good enough. No rush. I will pull together the list and send it to you off-list (with a cc to Bob). <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;">
<div style=""><div><span class="q"><blockquote type="cite"><div><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" target="_blank" onclick="return top.js.OpenExtLink(window,event,this)">
http://pyobjc.sf.net</a>].</blockquote><div><br>That's good to hear. </div></div></blockquote><div><br></div><div><br></div></span><blockquote type="cite"><div><br><span class="q"><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></div></span></div></blockquote><div><br></div>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).
</div><div><br></div><div>I know that some companies still use OS9 systems and binhex is used more in those environments. </div><div><br></div><div>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.
</div></div></blockquote><div><br><br>Well, based on that info binhex can stay.<br><br>-Brett<br></div></div>