[Pythonmac-SIG] Confused at the state of Python for OSX

[Alexandre Parenteau]

> Some of those mix & match orthogonal choices are:
> 
> Object Format:
> CFM/PEF  |  mach-o
> 
> Libraries linked against:
> GUSI  |  POSIX
> Carbon  |  Classic
> 
> Compiler:
> gcc | CodeWarrior  ( or MPW or other mac compilers )
> 
> Source Code:
> same code base but different macro definitions
> ( some defined by the compiler -- right now mostly
>  controlled by choice of compiler, but that should change. )
> 
> Support for various modules:
> Mac Toolbox (Carbon or "Classic")
> Cocoa (pyobjc)
> Tkinter ("Classic",  X11 libs or Carbonized Tk)
> OSX Scripting Component ( which also supports Cocoa scripting )

I'm not fully qualified to speak for the MacPython project, but from my
perspective using MacPython CFM on MacOSX is not an option on a long term.

We discussed online or offline this issue with Matthias Neeracher and Jack
Jansen, and we decided the GUSI port to Carbon for OSX was only transitional
and should not be used on a long basis.

Think about it : MacPython CFM is using GUSI, which emulates BSD on top of
Carbon, which is talking to BSD anyway. All my benchmark indicate that it is
a complete lost. And GUSI is already an obsolete thing for Matthias I think.

If you use MacOSX only, and this is my IMHO again, use the Mach-O port. It
will have everything that has the CFM version (including the MacOS
specific), only it will work much better with threads and sockets.

Now there are 2 kinds of problems by using Mach-O at the time we speak. Not
all the sub-components of Python are fully functional (like Tk-Inter) and
there is a legacy problem of people who are using either CodeWarrior or
existing CFM/Carbon libraries.

For the first problem, I believe it is only transitory.

As for the second, the CodeWarrior Mach-O support is already great, I had
the chance to test it (even though I cannot seem to be able to add
additional framework than the one inside /Systems/Library/Frameworks, which
is painful). I noted also you cannot debug a Mach-O binary which forks, but
the bug is the same in /usr/bin/gdb.

About the legacy of code now, I was thinking it would be easy to provide a
CFM glue code which loads and talk to the Mach-O binaries. The only problem
I foresee is about FILE from <stdio.h>. Some Python functions use the FILE
accessor and I don't think it is technically possible to share a FILE object
between CFM and Mach-O.

Alex.

-- 
Alexandre Parenteau
Computer Scientist
Core Technologies, AGM
Adobe Systems, Inc.
408-536-6166