[Pythonmac-SIG] Using a unix Python with a MacPython Lib tree

[Steven D. Majewski]

On Thu, 5 Apr 2001, Jack Jansen wrote:

> Maybe this can be seen as proving Just's point (do more in Python): by
> the time you've finished all the odds and ends you may have been
> better off implementing W in Cocoa so that you get IDE for free (and a
> lot more besides).
> 
> Hmm, on re-reading that paragraph: I definitely don't want to belittle
> your efforts, far from it! It's just that I tend to agree with Just:
> write as little C code as you possibly can, and use Python to glue it
> all together.

I certainly agree with the sentiment: do it in Python. 

In reality, neither Carbonmodule or PyObjC for Darwin-Python are
quite up to it yet. But they are pretty darn close. 

Last time I tried it, W died on one of the Qd.GetCursor().data 
calls in Wbase.py -- I'm sure because it's a unix object image
without any resource fork, so it only worked for the standard
ones that were in the Carbon framework somewhere. 

The other missing bit for running any of the Mac Python GUI scripts
is that MacOS module isn't ported, so there's no SchedParams() 
function. 


The problems with Cocoa have been more mysterious mainly because
I've been learning Cocoa as I go along. You can do some simple
GUI stuff now with PyObjC, but to get a real Cocoa Application
from Python, the fatal bugs are that Delegates aren't working correctly,
and that most of the methods that handle Nibs are all marked
"Description Forthcoming"  in the Docs! 

Johnathan -- after you've figured out Cocoa, I hope you'll sign up
at Sourceforge.net/projects/pyobjc -- so far BBum and I have been
the only ones that have taked a hack at it, and neither of us have
been able to spend a lot of time on it. 

Jack -- I think your  CVS is still missing a couple of files to 
be able to build Carbonmodule on OSX. I thought I had sent them
to you, but I'll take a look again and do a diff between my 
sources and the CVS files. 

Later -- I've got to run. 
-- Steve