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

[Just v. R. <ju...@le...>]

bb...@ma... wrote:

> 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.

Ok. However, the tool I have in mind is not specific to pyobjc. (I personally
don't use PB yet, and I'm not sure I will anytime soon.)

> > - 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.

Ok, I see the [NSUserDefaults standardUserDefaults] line. User defaults? How
does this work? Is it an entry in the Info.plist? If so, how come that's called
a user default? It it really _is_ a user default: it should be an app setting.

> > - 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.

I had to look at it the first time I tried to use it with a different Python
than the 10.2-shipped.

> > - 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.

Ok. However, the idea to just make a custom execve wrapper which (eg.) hardcodes
the real executable and/or the main Python program appleals to me. It's just so
simple.

> > - 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.

True. But what if you'd want to muck with argv before passing it along to the
child process?

> > - 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. 

Ok, just to make that 100% clear: I'm not even kidding ;-)

> Python is a wonderful language, but there is a lot of value in other
> languages...

Sure. Obj-C may kick some major butt compared to C (or even C++), but compared
to Python it's a big fat pain in the butt. Hey, a language war! ;-)

> 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. 

I don't follow this. Why would you load Frameworks in main.m if you're
execve-ing another _process_?

> 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.

Ok, I guess I'll have to learn more about this. Isn't "import AppKit" all that's
needed?

> 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].

I actually _like_ the flexibility of doing an execve. Bootstrapping code in
Python, what more could one want? ;-)

> 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.

But it remains purely an IDE problem, no?

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

Not sure if I follow you. I think both the main.m and the Python execve wrapper
can exist next to each other. I'll write the one, you the other ;-) Peace...

Just