[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