Re: [Pyobjc-dev] pyobjc on 2.2.1 & non-framework builds

[Bill B. <bb...@co...>]

On Tuesday, September 24, 2002, at 12:32 PM, Ronald Oussoren wrote:
> On Monday, Sep 23, 2002, at 19:13 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>
>> I'll have to revisit Jack's PythonLauncher when I have more time-- it 
>> has some serious issues/bugs.
>
> Such as? IMHO it would be better not to fork python, the situation is 
> hazy enough. I'd like to see a python-based PythonLauncher in the 
> future, but that is a completely different story.

In general, the application appears to have been created by someone who 
doesn't have an understanding of how to leverage the Cocoa APIs in a 
pattern that is consistent with the API's design.  This is not a 
criticism of Jack -- he is obviously a brilliant developer.   The 
application could use to be rewritten.

Also, the application uses the system() call to pass control into the 
Python interpreter.  This effectively leaves the PythonLauncher as the 
parent process of the underlying "real" application.

In all, it solves a different problem than the problem presented by the 
goal of creating standalone fully Cocoa compliant applications.  
Namely, PythonLauncher is much more about invoking a particular script 
and much less about distributing a standalone ".app" that a user can 
simply double-click to use.

I'm going to focus on solving the specific problems related to 
standalone Py-Cocoa based applications first, then revisit 
PythonLauncher.

>
>>
>> It also requires a framework build of python.  This is completely 
>> unnecessary and incurs an arbitrary limitation [user has to have 
>> Python.framework around as opposed to using the standard 
>> out-of-the-box Python included with 10.2].
>
> Is the framework really necessary or is it only required because of 
> the current build procedure?

The framework isn't necessary at all.   Everything pyobjc related works 
fine with the "out of the box" install included with OS X 10.2.

>
> BTW. I'd prefer to have a framework install of python as the standard 
> python sometime in the future. Maybe in MacOSX 10.4........

I would rather see Python remain as open and cross platform compatible 
as possible.  In that context, a framework (or bundle) might be an 
appropriate means of encapsulating resources specific to the Macintosh 
extension modules.  I.e. the mac specific (OS X, really) resources 
would be shoved into PyMac.framework down in site-packages (assuming 
the macintosh support were to remain as a module).

   However, encapsulating all of python into a framework doesn't really 
add anything to the environment in terms of features and definitely 
makes for a weird twist when using the Mac platform.

b.bum