[Pythonmac-SIG] Python.framework under OS X

[Tim Lahey]

On Tuesday, July 24, 2001, at 07:59 AM, Jack Jansen wrote:
>
>>> 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.

Good point, I'm more than willing to defer to others on this point.

>
> 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 Palette so
>>>> applications can embed the interpreter inside the application
>>>> along with a place for user interaction.
>>
>> 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?

Yes, one can extend IB to some extent. When I'm talking about an IB 
widget,
I'm talking about one of the items on the Cocoa/Carbon Views palette 
that users
use to build their UI. So, one can add their own items to it. Hmm, it 
appears
that only Cocoa allows this at the moment (When you start IB there is a 
list of
different items to build, one is an IB Palette). The IB Palette is based 
upon a
Cocoa class that the user has written.

>
>> 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'm not sure, I don't think so at the moment. Something to ask on the 
Project Builder
mailing list, I think. One way to emulate it would be to have a tool 
that takes the
generated .m files and converts them to PyObjC. Either that or builds 
them from the
NIB files. I don't think this can be done with the existing Interface 
Builder.

Cheers,

Tim Lahey
tjlahey@cgl.uwaterloo.ca