Re: [Pyobjc-dev] Reason not to use the python based main

[<bb...@ma...>]

On Monday, November 18, 2002, at 02:18 PM, Just van Rossum wrote:
> Hm, basing a coding decision on one specific feature of one specific 
> IDE?
> Bleh...

Normally, I would agree... however, seeing that PBX is the standard and 
free IDE included with the platform and, therefore, is accessible to 
every single developer on the platform and that installation of the Dev 
Tools also installs all the documentation that the developer needs for 
effective development using PyObjC, it would seem that basic decisions 
on the PBX IDE is in line with the desired direction for the module.

> - the current main.m doesn't work if the python executable isn't 
> /usr/bin/python

Not true;  set PythonBinPath default to whatever you want.

> - it's 50 lines of dense Obj-C code instead of 5 sparse lines of Python

50 lines that no developer ever has to look at;  plus, that 50 lines 
packs quite a few more features into than the 5 lines of python.

> - the executable can't easily be created from a template

Why would it need to be created from a template?   Once the executable 
exists-- it could/should be shipped as a part of the PyObjC module-- it 
can be copied into any application and it will "just work".  It can be 
renamed, if so desired.

> - it depends on dev-tools being available, can't be built from pure 
> Python

Why would it need to be compiled?  It "just works" as is.  Just copy it.

> - why would one _ever_ want to use Obj-C if the same can be done in 
> Python and
>   speed is not an issue?

I was kind of expecting to see a :-) on that statement.  Python is a 
wonderful language, but there is a lot of value in other languages...

In any case, the ObjC version offers features that cannot be 
implemented in Python. Notably, the automatic handling and loading of 
frameworks cannot be done without some manual effort on the part of the 
developer.  The current bin-python-main.m allows the developer to link 
the frameworks into the project as they would in any normal PBX based 
project and the __main__.py and bin-python-main.m will take care of 
ensuring that they are also dynamically loaded once control is turned 
over to the python interpreter.

Of course, all of this is just a workaround until Apple ships an 
embeddable interpreter [though, even once they do, it may be sometime 
before everyone in the market has upgraded to a version of the OS with 
the appropriate dylib in place].

The point of the PyObjC bridge is to provide a transparent bridge 
between Python and Objective-C such that a developer can freely mix and 
match the two at will.   The compiled executable based approach 
preserves the full OS X development experience for those that choose it 
while taking away nothing from those that choose to go the pure-Python, 
non Apple Dev Tools, approach.   The same cannot be said for the pure 
python main.

There isn't a reason-- beyond yet-another-moving-part-to-maintain-- 
that we can't ship both.

b.bum