PyObjC

On 20-dec-2004, at 2:16, Mario Diana wrote:



> Hello,
>
> I am trying to pass a method object but have ended up without a 
> callable object! Here's the description.
>
> From my PyObjC Controller object I instantiate a Python object, 
> passing it method (as an object) from the Controller as an argument. 
> What I would like is for my Python object to callback to the 
> Controller when the Python object executes one of its methods.
>
> The problem I'm having is the Python object does not seem to be 
> receiving the Controller's method as an object. When the callback 
> executes, I get the following error message:
>
>     File "/usr/local/lib/groklog/recordCount.py", line 69, in execute
>     self.callback(line)
>     TypeError: 'str' object is not callable
>
> My Python object prints a debug statement when it receives the 
> Controller's method, the result of which is this:
>
>     <selector printLineToView of <Controller objective-c instance 
> 0x456ab0>>
>
> "printLineToView" is the Controller's method.
>
> Is it possible that my Python method is receiving a string object 
> instead of the Controller-method-object? That's what the error message 
> leads me to believe.
>
> So, is there a way to pass a method as an object from a PyObjC 
> Controller to pure Python code? I'm guessing the whole "selector" 
> thing is what's throwing my code off.

Maybe, maybe not. It would help if you included some code, preferable a 
script that demonstrates the behaviour your seeing.

Ronald

On Sun, 19 Dec 2004 20:16:19 -0500, Mario Diana <mariox19@...> wrote:
>  From my PyObjC Controller object I instantiate a Python object, passing
> it method (as an object) from the Controller as an argument. What I
> would like is for my Python object to callback to the Controller when
> the Python object executes one of its methods.

On this topic, are there any pointers someone could provide for moving
away from Xcode and towards py2app, but mixing ObjC code with bridged
Python code?  I'm wanting to code the UI in ObjC, and have its model
objects reach across the bridge to the Python code for their content.

While I can do this currently with the Xcode templates, is there a way
via py2app to compile and link it all together, given the recent
changes away from bundlebuilder toward py2app?

I'd be most happy with an Xcode template that uses py2app for
packaging, so that IB/Xcode integration remains consistent, and that
all the current example code and offical Apple docs would suffice to
understand and maintain (and in the future, modify) the UI with IB.

It would also allow for an easier time with regards to bindings and a
few other things in a certain future OS that may not be wrapped yet..

I admit to not being that familiar with the innards of Xcode's build
system, but if there's anything I can do to help, please point me in
the right direction :)

Thanks,

J.

On Dec 19, 2004, at 21:42, Jordan Krushen wrote:

> On Sun, 19 Dec 2004 20:16:19 -0500, Mario Diana <mariox19@...>  
> wrote:
>>  From my PyObjC Controller object I instantiate a Python object,  
>> passing
>> it method (as an object) from the Controller as an argument. What I
>> would like is for my Python object to callback to the Controller when
>> the Python object executes one of its methods.
>
> On this topic, are there any pointers someone could provide for moving
> away from Xcode and towards py2app, but mixing ObjC code with bridged
> Python code?  I'm wanting to code the UI in ObjC, and have its model
> objects reach across the bridge to the Python code for their content.

Since so much of your code is going to be written in Objective-C and  
not Python, why not just write a plugin that contains your model  
objects?

See:  
http://svn.red-bean.com/pyobjc/trunk/pyobjc/Doc/tutorial_embed/ 
extending_objc_with_python.html

> While I can do this currently with the Xcode templates, is there a way
> via py2app to compile and link it all together, given the recent
> changes away from bundlebuilder toward py2app?

This will create a py2app setup.py from a subset of projects based on  
the Xcode template (though that subset may just be ReSTedit):
http://svn.red-bean.com/pyobjc/trunk/pyobjc/sandbox/xcode_py2app/ 
create_setup_from_xcode.py

> I'd be most happy with an Xcode template that uses py2app for
> packaging, so that IB/Xcode integration remains consistent, and that
> all the current example code and offical Apple docs would suffice to
> understand and maintain (and in the future, modify) the UI with IB.

Interface Builder and Xcode probably don't integrate as much as you  
think they do.

Using py2app in the Xcode build process would be awfully painful, and  
I'm certainly not going to do it anytime soon (that means, DEFINITELY  
not 1.2).  Ideally, more of Xcode's APIs would be open, and I could  
just write a plugin for Xcode that does it, but I can't (without a  
significant reverse-engineering effort).  The next best way, I guess,  
would be to make a py2app build mode that would run as a post-build  
script and analyze an existing half-assed application bundle that Xcode  
would build doing things the way it normally would.  This would add  
stuff to the Info.plist, and shove a bunch of new files and/or modify  
files based upon what the dependency analysis decides to do.  This  
would be suboptimal because supporting an alias bundle build mode  
(ideal for development) would be near impossible from Xcode without  
reading in the project file, and the main script would probably have to  
be figured out by naming convention (pyobjc_main.py, or something).

> It would also allow for an easier time with regards to bindings and a
> few other things in a certain future OS that may not be wrapped yet..

That doesn't really have anything at all to do with Xcode.

> I admit to not being that familiar with the innards of Xcode's build
> system, but if there's anything I can do to help, please point me in
> the right direction :)

You can work on that script if you want, but be warned that Xcode  
projects are like pickle files and you're coding against private  
implementation details.  They probably won't change them much, but  
Apple certainly could do whatever they want in a future version of  
Xcode and break everything.

-bob

On Monday, December 20, 2004, at 02:05  AM, Ronald Oussoren wrote:

> It would help if you included some code, preferable a script that 
> demonstrates the behaviour your seeing.

I wrote the simplest demonstration case of my problem with the 
intention of posting it to the list. Lo and behold, the "simplest case" 
worked. My guess is I have introduced some kind of problem into my code.

I should have tried the above before posting to the list in the first 
place. (That's good manners, right?) Anyway, when I get home from work 
I'll try to solve what I've done wrong. If I make no progress, or if I 
come up with anything interesting, I'll repost.

Thanks again to everyone who responded!

Mario

On Dec 20, 2004, at 3:52 PM, Jordan Krushen wrote:

> On Mon, 20 Dec 2004 06:08:10 -0500, Bob Ippolito <bob@...> 
> wrote:
>
>> Since so much of your code is going to be written in Objective-C and
>> not Python, why not just write a plugin that contains your model
>> objects?
>
> You'd mentioned previously that the plugin handling was kinda hackish,
> so I didn't think it was deployable yet.  Are we talking about the
> same plugin procedure?  embed_tutorial or the __plugin_hack__ (sic?)
> thing?

It's perfectly deployable, and it's not hackish.  There is one hack 
present that works around a NSBundle misfeature for exactly one class 
per plugin, which is sufficient for just about anything, if necessary 
at all.

>> Interface Builder and Xcode probably don't integrate as much as you
>> think they do.
>
> I understand that it's all superficial, but I'm trying to give the
> client something they can hire someone else to modify (at least the
> UI), using standard tools.

Well, standard tools in this case is Python with a setup.py.

>>> It would also allow for an easier time with regards to bindings and a
>>> few other things in a certain future OS that may not be wrapped yet..
>>
>> That doesn't really have anything at all to do with Xcode.
>
> No, but KVO/KVC aren't exactly seamless yet when being passed across
> the bridge  -- it has to do with ObjC v. Python, and if I'm writing in
> ObjC, why not use Xcode?  To be honest, I don't really care what the
> editor is.   All I want is a way to compile the ObjC and the PyObjC
> stuff together into an app that works, and all I hear is that plugins
> are a hack, that it can only handle one class, or that Xcode is
> deprecated.. please correct me if I'm wrong :)

KVO / KVC works just fine across the bridge if you follow the same 
constraints as you would from Objective-C, namely, don't touch instance 
variables directly.  Yes, if you define accessor methods, you will have 
to use @objc.accessor (or longer non-decorator equivalent).

You are wrong, plugins are not a hack.  The only aspect of plugins that 
are a hack is the fact that it's only possible to have one class "do 
the right thing" with +[NSBundle bundleForClass:].  This is only really 
applicable to your NSPrincipalClass, if even then, unless you introduce 
code that uses it internally.  So, you don't need more than one class 
to respond "correctly" from NSBundle.

Xcode projects are more or less deprecated for deployment.  They don't 
work any better or worse than they did before.  py2app based 
applications work much better.

-bob

On Mon, 20 Dec 2004 06:08:10 -0500, Bob Ippolito <bob@...> wrote:

> Since so much of your code is going to be written in Objective-C and
> not Python, why not just write a plugin that contains your model
> objects?

You'd mentioned previously that the plugin handling was kinda hackish,
so I didn't think it was deployable yet.  Are we talking about the
same plugin procedure?  embed_tutorial or the __plugin_hack__ (sic?)
thing?

> Interface Builder and Xcode probably don't integrate as much as you
> think they do.

I understand that it's all superficial, but I'm trying to give the
client something they can hire someone else to modify (at least the
UI), using standard tools.

> > It would also allow for an easier time with regards to bindings and a
> > few other things in a certain future OS that may not be wrapped yet..
> 
> That doesn't really have anything at all to do with Xcode.

No, but KVO/KVC aren't exactly seamless yet when being passed across
the bridge  -- it has to do with ObjC v. Python, and if I'm writing in
ObjC, why not use Xcode?  To be honest, I don't really care what the
editor is.   All I want is a way to compile the ObjC and the PyObjC
stuff together into an app that works, and all I hear is that plugins
are a hack, that it can only handle one class, or that Xcode is
deprecated.. please correct me if I'm wrong :)

> You can work on that script if you want, but be warned that Xcode
> projects are like pickle files and you're coding against private
> implementation details.  They probably won't change them much, but
> Apple certainly could do whatever they want in a future version of
> Xcode and break everything.

Agreed.. that's not my preferred way of doing things, either.

I'm not complaining, I'm just trying to sort out the best way to
attempt things for this next project.

Thanks again for your help,

J.

On Mon, 20 Dec 2004 16:04:55 -0500, Bob Ippolito <bob@...> wrote:

> You are wrong, plugins are not a hack.  The only aspect of plugins that
> are a hack is the fact that it's only possible to have one class "do
> the right thing" with +[NSBundle bundleForClass:].  This is only really
> applicable to your NSPrincipalClass, if even then, unless you introduce
> code that uses it internally.  So, you don't need more than one class
> to respond "correctly" from NSBundle.

So to make sure I have this right, I can have several bundles with one
class each without using anything considered hackish?  I had problems
with the tutorial_embed example earlier today, but I'll grab a fresh
trunk and try it again.

> Xcode projects are more or less deprecated for deployment.  They don't
> work any better or worse than they did before.  py2app based
> applications work much better.

Would I be right in guessing that an Xcode ObjC project using a few
py2app-made plugins would be fine, assuming the plugins don't conflict
with each other?

I know you probably don't recommend this, but would it be possible to
install/run cfreactor in a plugin? :)

I admit to constanly being surprised at the many different ways the
bridge can be used!

J.

On Dec 20, 2004, at 4:57 PM, Jordan Krushen wrote:

> On Mon, 20 Dec 2004 16:04:55 -0500, Bob Ippolito <bob@...> 
> wrote:
>
>> You are wrong, plugins are not a hack.  The only aspect of plugins 
>> that
>> are a hack is the fact that it's only possible to have one class "do
>> the right thing" with +[NSBundle bundleForClass:].  This is only 
>> really
>> applicable to your NSPrincipalClass, if even then, unless you 
>> introduce
>> code that uses it internally.  So, you don't need more than one class
>> to respond "correctly" from NSBundle.
>
> So to make sure I have this right, I can have several bundles with one
> class each without using anything considered hackish?  I had problems
> with the tutorial_embed example earlier today, but I'll grab a fresh
> trunk and try it again.

You can have several bundles with 4000 classes each with nothing 
considered hackish.  Again, the ONLY TIME YOU EVER NEED +[NSBundle 
bundleForClass:] to return the right thing (and therefore, 
__plugin_hack__) is if the plugin-loading-code expects it to work, in 
your case, it doesn't, so you don't need it at all.  In some cases, 
like with Interface Builder plugins, it expects this to be true for the 
NSPrincipalClass.  I have never seen an application that expects this 
to be true for any more than that.

>> Xcode projects are more or less deprecated for deployment.  They don't
>> work any better or worse than they did before.  py2app based
>> applications work much better.
>
> Would I be right in guessing that an Xcode ObjC project using a few
> py2app-made plugins would be fine, assuming the plugins don't conflict
> with each other?

I would recommend using as few plugins as possible, because it's all 
the same Python interpreter anyway, and it's going to be MUCH easier to 
debug and build with just one plugin.  Especially if they have some 
common dependencies or something.

> I know you probably don't recommend this, but would it be possible to
> install/run cfreactor in a plugin? :)

You can run whatever the hell you want in a plugin.. but since the 
Python interpreter *is* shared, you have to make sure that the first 
plugin to use Twisted is going to install cfreactor.

-bob

On Mon, 20 Dec 2004 17:07:30 -0500, Bob Ippolito <bob@...> wrote:

> You can have several bundles with 4000 classes each with nothing
> considered hackish.  Again, the ONLY TIME YOU EVER NEED +[NSBundle
> bundleForClass:] to return the right thing (and therefore,
> __plugin_hack__) is if the plugin-loading-code expects it to work, in
> your case, it doesn't, so you don't need it at all.  In some cases,
> like with Interface Builder plugins, it expects this to be true for the
> NSPrincipalClass.  I have never seen an application that expects this
> to be true for any more than that.

Excellent, thanks.

> I would recommend using as few plugins as possible, because it's all
> the same Python interpreter anyway, and it's going to be MUCH easier to
> debug and build with just one plugin.  Especially if they have some
> common dependencies or something.

One is plenty for me, I think.

> You can run whatever the hell you want in a plugin.. but since the
> Python interpreter *is* shared, you have to make sure that the first
> plugin to use Twisted is going to install cfreactor.

Yup.  Thanks again.

J.