[Pythonmac-SIG] Python.framework under OS X

[Jack Jansen]

> As for the structure of the framework, I'm more than willing to defer to 
> others. The
> main reason I see for a framework is the ease of installation and 
> inclusion with
> an application. I'd rather not hide things in /usr/local/lib/pythonx.x, 
> it doesn't
> really fit with the general OS X philosophy.

Yep, fully agreed.

> > I think I'd prefer the global site-packages to live in 
> > Lib/site-packages in
> > /Library/Framework/Python.framework/ just so we're not accused of 
> > changing
> > things without reason (by the rest of the unix-pythoneers). The
> > ~/Library/Python idea I like.
> 
> The only problem I have with this is that it means that the contents of 
> the framework
> will be exposed and edited by the users.

Hmm, yes, that's right. And it shouldn't be too difficult to explain distutils 
that site-python is in a different place on OSX.

On the other hand, there's still the problem that this will be unfamiliar to 
people with a unix background, and I think that keeping the unixheads happy is 
a good thing (especially if it can lure people over to the Mac!).

Ah, I think I see a showstopper for the /Library/Python idea: there's no 
version control in there, whereas in /Library/Framework/Python.framework there 
is. And version control is important to distutils-based packages, as they may 
contain dynamically loadable modules.

Hmm, but for pure-Python packages /Library/Python may well be the better 
place.... I'm not sure yet, any other views are welcome...

> >> 4. Create a PythonInterpreter View Interface Builder Pallet so
> >> applications can embed the interpreter inside the application
> >> along with a place for user interaction.
> >
> > Oops, buzzword overload. I know the various words, but the stringing 
> > together
> > doesn't result in added meaning. Could you expand on this a bit?
> 
> Basically, I want a IB widget that one can add to their application that 
> provides
> an interpreter view.

This all sounds like magic to me. What is an IB widget? Do I understand that I 
can extend IB? How?

> The way I see things is that people will have two ways of building a UI 
> for their
> application:
> 
> 1. In python, using a wrapper around Carbon calls.
> 2. In Cocoa/Carbon, with python embedded in the application, but not 
> creating
> the UI.

Is there a way we could emulate the magic that IB does for Cocoa for 
Objective-C and Java?

In my opionion Python is a language that could potentially be much better 
integrated with IB than Objective-C (I've never tried Java yet). For one, the 
"generate source files" could simply output readonly files that contain base 
classes that you then import and subclass in your own Python class. This gets 
rid of the problem that you have can't really press the "generate" button for 
ObjC after you've modified the sources (unless you're willing to risk your 
code disappearing).

(In the paragraphs above I'm assuming that Steven will get the Python<->ObjC 
bridge working).

> I think both have their place. One way of doing an IDE for OS X python 
> would be
> the second.

Yes, but an easier way would be to take the existing IDE and pack it up as an 
application using the Python.framework. The main body of work here is either 
porting Waste or replacing it by MLTE. The other modules it needs all run 
(well, compile:-) under MachO-Python already. Of course there's more work, but 
that's only minor things.


--
Jack Jansen             | ++++ stop the execution of Mumia Abu-Jamal ++++
Jack.Jansen@oratrix.com | ++++ if you agree copy these lines to your sig ++++
www.oratrix.nl/~jack    | see http://www.xs4all.nl/~tank/spg-l/sigaction.htm