[Pythonmac-SIG] Communicating With Apple

Bob Ippolito bob@redivi.com
Tue, 15 Apr 2003 16:57:27 -0400


On Tuesday, Apr 15, 2003, at 16:36 America/New_York, Nick Matsakis 
wrote:

> On Sat, 12 Apr 2003, Bob Ippolito wrote:
>
>> I'd make it easy for the user who is compiling Python 2.3 to decide
>> whether they want /System/Library/Python or not.  Whoever maintains
>> Python for Apple would probably appreciate this, because that's their
>> style, and we can all cross our fingers and hope that 2.3 will be
>> compiled and distributed PROPERLY with OS X 10.3.X or 10.4.
>
> It seem to me that this is much, much too important of an issue to just
> hope Apple gets right.  I've already asked on this list: "_Why_ did 
> Apple
> include Python with 10.2?" and it seems that no one knew the answer. I
> think this is a vital question and that now is the time to address it, 
> not
> after Panther comes out.
>
> The reason to ask "why?" is that the answer provides a sense of where
> Apple is coming from.  If Python was included simply as a part of 
> Darwin,
> then there is no reason to expect that Pather will include anything 
> more
> than a vanilla-unix Python installation since Darwin does not include 
> the
> carbon frameworks or other "Mac" libraries.  If it is included as a 
> "Mac
> OS X" feature, then it is important to ensure that they provide a 
> stable
> version where the Macpython extensions work as expected.  In either 
> case,
> communication with Apple at this point is important.
>
> Is anyone in a position to answer these questions?  Or, is anyone who
> is going to WWDC willing to bring up these issues?

Just to clarify, it is hardly sufficient even as a Darwin version of 
Python:

1) dyld
The dynamic linker is busted.. it uses a completely flat namespace 
somehow (not related to the -flat_namespace flag), an extension named 
time.so in builtins is considered the same as one named pygame/time.so 
in another package.  It recognizes that they both exist, but only ends 
up loading one of the two.  This is a problem, and is unfixable without 
recompiling Python itself (dyld isn't and can't be a dynamically linked 
module)  They _obviously_ didn't test this at all because.....

2) distutils
Distutils is broken (won't compile extensions) because of the notorious 
-arch i386 in the Makefile.. If anyone at Apple actually used Python, 
they'd probably have noticed this?  It also uses -flat_namespace 
instead of doing it -bundle_loader style, why?  I modified mine to use 
two-level namespaces (to resolve some issues with SWIG) and 
bundle_loader, and it works just fine even with their broken python 
executable.

3) missing modules
It doesn't have expat, even though expat is part of the Python source 
tree.  Plist files are everywhere, and stock python can't parse XML 
without the expat module (although Twisted comes with a pure python 
sax-like parser and minidom replacement.. so this doesn't bother me 
personally too much).

It doesn't have readline, which is pretty essential to using python 
interactively on the command line.. this can be pretty easily compiled 
with instructions from bbum, but come on.

It doesn't have ssl support, which I guess doesn't matter so much 
because python's ssl module is pretty crummy compared to pyopenssl.

4) Python 2.2.0 has a lot of issues as-is
Python 2.2.0 was a buggy release, it has problems with the gc module.. 
seems to have problems with the weakref module, and new style classes 
are broken in some respects (__new__ is the primary example, I think).

----

In any case, I plan on going to WWDC (I have a ticket, at least).. so 
perhaps I'll have the opportunity to bring up this concern.  At the 
least, I expect (well, hope) Apple releases Panther with a clean 
version of Python 2.2.2 that has the above 4 issues resolved.  
Backports of most Macpython 2.3 modules/features are relatively trivial 
once you know what you're doing, but doing them to a broken Python is 
too much work, and sometimes you just run into things that you can't 
fix.

-bob