[Pythonmac-SIG] Communicating With Apple

[Bugbee, Larry]

WWDC is in late June.  That may be too late for Panther.

Larry

-----Original Message-----
From: Bob Ippolito [mailto:bob@redivi.com]
Sent: Tuesday, April 15, 2003 1:57 PM
To: Nick Matsakis
Cc: pythonmac-sig@python.org
Subject: Re: [Pythonmac-SIG] Communicating With Apple



On Tuesday, Apr 15, 2003, at 16:36 America/New_York, Nick Matsakis=20
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=20
> 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=20
> Darwin,
> then there is no reason to expect that Pather will include anything=20
> more
> than a vanilla-unix Python installation since Darwin does not include=20
> the
> carbon frameworks or other "Mac" libraries.  If it is included as a=20
> "Mac
> OS X" feature, then it is important to ensure that they provide a=20
> stable
> version where the Macpython extensions work as expected.  In either=20
> 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=20
Python:

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

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

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

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

It doesn't have ssl support, which I guess doesn't matter so much=20
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..=20
seems to have problems with the weakref module, and new style classes=20
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=20
perhaps I'll have the opportunity to bring up this concern.  At the=20
least, I expect (well, hope) Apple releases Panther with a clean=20
version of Python 2.2.2 that has the above 4 issues resolved. =20
Backports of most Macpython 2.3 modules/features are relatively trivial=20
once you know what you're doing, but doing them to a broken Python is=20
too much work, and sometimes you just run into things that you can't=20
fix.

-bob


_______________________________________________
Pythonmac-SIG maillist  -  Pythonmac-SIG@python.org
http://mail.python.org/mailman/listinfo/pythonmac-sig