On Jul 20, 2004, at 10:29 AM, Jonathan Wight wrote:
> On Jul 20, 2004, at 01:25, b.bum wrote:
>>> Typical usage of PyObjC is python "on the outside", as used in the
>>> Xcode templates. It's far easier to expose ObjC to Python than vice
>>> versa, so that's what we do. It doesn't really make sense to make
>>> it a framework until it's part of Python, and that's not going to
>>> happen for a good long time (Python 2.5 at the earliest, I guess).
>> True if you come from Python... if you are an old-hand ObjC head,
>> PyObjC can be construed as being the other way around. :-)
> Which is what I want. I want to use Python as a purely embedded
> language. I was hoping to use PyObjc as a bridge to shunt data between
> ObjC and Python (effectively I was hoping to write my model code in
> Python and view/controller in plain old ObjC). It's possible my Python
> code will call back into ObjC but I'm going to avoid that as much as
> possible (the code needs to be cross-platform).
>> Seriously, the bridge really tries to be transparent, it just happens
>> to be easier to pass objects into Obj-C from Python than the other
>> way around. Once the object references exist on either side of the
>> bridge, messaging the objects should "just work". When going from
>> Obj-C -> Python, the one bit of complexity is dealing with types. In
>> general, if you stick to straight objects, life will be easier.
> Yep - sticking to straight objects (NSDictionaries, NSStrings,
> NSValues for now). If I do need to get C types into Python I'll most
> likely wrap them in NSValues.
>> Alternatively, you can do this:
>> - create an Abstract class that contains the API you want to
>> implement in Python
>> - implement subclasses of the Abstract class in Python. I.e.
>> class Foo(MyAbstractObjCClass):
>> - make sure the concrete subclasses are imported into the Python
>> - instantiate the concrete subclasses (from python or ObjC, doesn't
>> - invoke the methods as you normally would
>> This has several advantages:
>> - it is easy (once you figure out what the hell I'm talking about...
>> it really is easy!)
>> - since the method signatures exist on the super, the invocations
>> into python will automatically deal with all the argument types
>> - the ObjC compiler won't complain because you are providing dummy
>> implementations on your abstract class
> But I'd imagine all the objects (standard Foundation objects) I need
> already work? So this effort is just for custom classes?
*ALL* objects work. The problem is that not all selectors are
guaranteed to work out of the box if they take
> For Foundation objects Bob's PyObjC_IdToPython() seems ideal. The
> trouble is accessing it. Looking at the examples doesn't help - they
> all seem to be bundlebuilder based and I don't want the python binary
> to be my application's binary. The template created projects seem to
> be a better proposition - but I don't understand why python is loaded
> via NSAddImage and symbols looked up explicitly instead of just
> linking to Python.framework.
It does linking itself so that:
- the executable stub only needs to be compiled once, ever, if you're
not using any additional ObjC code (not currently used in practice)
- the app can give a useful GUI error dialog if the BSD subsystem isn't
installed (which means Python.framework doesn't exist)
- the app can give a useful GUI error dialog if the app is run on the
wrong version of Mac OS X
.. among other reasons that are harder to explain.