pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Seth D. <se...@jt...>]

On Wednesday, October 16, 2002, at 03:10 , Bob Ippolito wrote:
>
> On Wednesday, Oct 16, 2002, at 17:45 America/New_York, bb...@ma... 
> wrote:
>> However, I completely fail to see how...
>>
>>     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>>
>> ... is cleaner/clearer/better than...
>>
>>     obj.drawSelfAtPoint_color_withSize_(p, c, s)
>
> It's not.  Though, I can see how it'd be kinda useful in strange cases 
> to have the "rt.call" function around.

I'll never 'win' this discussion, as if that is meaningful, but the 
syntax serves another purpose.  The main reason I like it is because I 
don't like calling conventions that list parameter names and values in 
separate places.  With the underscore convention, you have essentially 
(pseudocode):

call((a,b,c), (1,2,3))

when the *meaning* is

call(a=1, b=2, c=3).

But I'm definitely not the target audience for pyobjc, so I would ignore 
all of my comments at this point.  I love Python and I love 
Objective-C.  I see no reason to write GUI Cocoa code in Python when 
Objective-C does it perfectly and the GUI api was meant for use with 
Objective-C.

I thus think it would be far more useful to have a simple way to link an 
Objective-C nib-based GUI controlled by a Python backend, with 
convenience wrappers to convert complex library types like dictionaries 
and mutable arrays.

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[tmk <li...@ne...>]

On Thursday, Oct 17, 2002, at 00:32 Europe/Brussels, Jack Jansen wrote:

>
> On woensdag, oktober 16, 2002, at 05:34 , bb...@ma... wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Yes on both counts. That's exactly what encouraged to actually try and 
write some code using the alternative syntax. And indeed, soon enough 
it so happens that the "_" notation just "grew" on me and became quite 
natural. I think it's because it "reads" effortlessly, whereas I needed 
to pause and decipher the innercased notation.

> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And

Funny. Same here. But that was the notation with the double underscore 
(if memory serves I even de-lurked at that time just to say that I felt 
the syntax looked really UGLY ;-). But with one underscore, as said 
previously, it makes a lot of sense to me (much more than the 
alternatives anyway).

One other thing, A paradox, I tend to dislike using underscores when I 
write "regular" python code. I prefer using InnerCased (?) style. Funny 
brain.

>  I've heard of more people with this reaction. So, if we care about 
> winning existing Python programmers over to Cocoa (which I think we 
> should: even though Carbon is going to be around for a long time it'll 
> only be interesting to existing Mac programmers, and Cocoa has the 
> potential to win over unix and windows Python people) we should make 
> sure it looks appealing.
> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

Looks like a reasonable compromise. But I suspect (based on my humble 
experience) that most people will eventually use the "_" naturally 
(same as C programmers who first don't want to learn ObjC and then fall 
in love with it ;-)

= tmk =

> --
> - Jack Jansen        <Jac...@or...>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[tmk <tm...@ma...>]

On Thursday, Oct 17, 2002, at 00:32 Europe/Brussels, Jack Jansen wrote:

>
> On woensdag, oktober 16, 2002, at 05:34 , bb...@ma... wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Yes on both counts. That's exactly what encouraged to actually try and 
write some code using the alternative syntax. And indeed, soon enough 
it so happens that the "_" notation just "grew" on me and became quite 
natural. I think it's because it "reads" effortlessly, whereas I needed 
to pause and decipher the innercased notation.

> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And

Funny. Same here. But that was the notation with the double underscore 
(if memory serves I even de-lurked at that time just to say that I felt 
the syntax looked really UGLY ;-). But with one underscore, as said 
previously, it makes a lot of sense to me (much more than the 
alternatives anyway).

One other thing, A paradox, I tend to dislike using underscores when I 
write "regular" python code. I prefer using InnerCased (?) style. Funny 
brain.

>  I've heard of more people with this reaction. So, if we care about 
> winning existing Python programmers over to Cocoa (which I think we 
> should: even though Carbon is going to be around for a long time it'll 
> only be interesting to existing Mac programmers, and Cocoa has the 
> potential to win over unix and windows Python people) we should make 
> sure it looks appealing.
> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

Looks like a reasonable compromise. But I suspect (based on my humble 
experience) that most people will eventually use the "_" naturally 
(same as C programmers who first don't want to learn ObjC and then fall 
in love with it ;-)

= tmk =

> --
> - Jack Jansen        <Jac...@or...>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>

[Pyobjc-dev] running gdb against PyObjC based apps

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

Because the apps use execve() to transfer control to /usr/bin/python, 
you can't use gdb directly from ProjectBuilder.

However, you can use gdb!

Start the app such that it gets passed the execve().  Once python takes 
control, find the process identifier ### of the process (ps auxwww | 
grep 'Web Services Tool').

Then:

     gdb /usr/bin/python PID

You will now have a gdb session against that application that actually 
works!

It would be nice if the same could be done from within Project Builder, 
but I haven't investigated enough to see if it is possible.

b.bum

[Pyobjc-dev] DictType -> ObjC

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

Ronald,

     How hard would it be to proxy DictType, ArrayType, and TupleType 
into Obj-C such that they look/feel/act/behave/are subclasses of 
NSDictionary and NSArray?

     That is, such that they implement the primitive methods of the 
NSDictionary/NSArray class clusters and internally use the Py* APIs to 
retrieve/set values [converting as necessary]?

     This would be significantly valuable in that it doesn't imply a 
conversion as the objects come across the bridge from Python->ObjC, yet 
they would be compatible with NSDictionary/NSArray and friends.

     Also-- should the following slice fail in the way that it does?  (I 
included the last two lines only because it raises the question as to 
whether or not NSNumber/NSValue should be converted across the bridge 
-- I'm not sure that there is a really clear answer).

[bumbox:IssueCenter/V3/Python] bbum% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> x = NSMutableArray.array()
 >>> x.addObject_(1)
 >>> x.addObject_(2)
 >>> x.addObject_(3)
 >>> x.addObject_(4)
 >>> x.addObject_(5)
 >>> y = [1,2,3,4,5]
 >>> y[2:4]
[3, 4]
 >>> x[2:4]
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
   File "/usr/lib/python2.2/site-packages/objc/__init__.py", line 152, 
in <lambda>
     CONVENIENCE_METHODS['objectAtIndex:'] = ('__getitem__', lambda 
self, arg: self.objectAtIndex_(arg))
TypeError: expected an integer for argument 1: its typespec is 'I'
 >>> y[0]
1
 >>> x[0]
<NSCFNumber objective-c instance 0xc1a7c0>
 >>>


     b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Wednesday, October 16, 2002, at 06:32 PM, Jack Jansen wrote:
> On woensdag, oktober 16, 2002, at 05:34 , bb...@ma... wrote:
>> We have been down this path a number of times over the six year 
>> history of the PyObjC module.  In all cases, we have ended up back 
>> with the naming conventions that we have now for a number of reasons. 
>>   Moving from double underbar to single underbar was definitely a win 
>> -- made the code easier to read and write.
>
> I'm not convinced yet, but you're getting there:-)
>
> You're getting there because you have by far the most experience with 
> this beast, so if you say the _ convention is A Good Thing and 
> everything else leads to madness: okay, proof by authority:-) Also, 
> the point of ObjC-Cocoa programmers moving to Python is a valid one.

Let me clarify:  I don't necessarily think it is A Good Thing.  I'm 
just convinced that it is better than solutions that involve presenting 
a significantly mangled API on the other side of the bridge.

The current _ based mapping system falls clearly under the KISS 
principal -- it is simple, slightly ugly, and just works.

>
> I'm not convinced yet, though, because I think it depends on the 
> target audience. My first impression when I saw PyObjC code (about 18 
> months ago) was "UGLY!! UGLY!! UGLY!!", and I immediately stayed away 
> from it for a year. And I've heard of more people with this reaction. 
> So, if we care about winning existing Python programmers over to Cocoa 
> (which I think we should: even though Carbon is going to be around for 
> a long time it'll only be interesting to existing Mac programmers, and 
> Cocoa has the potential to win over unix and windows Python people) we 
> should make sure it looks appealing.

I completely agree (including the UGLY!! part).   A part of making it 
appealing is making it easier to work with or more powerful than 
working with the existing compiled ObjC based tools.

The current model-- though ugly from a traditional python viewpoint-- 
is easy to work with in that it is very easy to map between 
Python<->ObjC and it is extremely powerful-- more powerful than 
straight ObjC-- in terms of both rapid turnaround time and ability to 
leverage the vast wealth of Python tools/frameworks/libraries that are 
available.

> Let's try for a political solution. The official mapping is the _ 
> mapping. However, for convenience there are some method names that 
> have an alias. This alias is translated early on (when looking up the 
> method name from Python, or when creating the Python subclass of an 
> ObjC class), and the official name is used from then on. Would this be 
> workable?

(I would also like to see effort invested in making the ObjC classes 
behave like proper Python classes where possible and vice-versa.  For 
example, would it be possible to pass things of type PyDict across the 
bridge from Python->ObjC such that they behave like a subclass of 
NSMutableDictionary?  I think so, but am not sure.)

As much as I have been extremely vocal in my opinions on this subject, 
I'm also a very reasonable solution.  As long as the underlying system 
remains as transparent and workable-- though UGLY!!-- as it currently 
is, I'm all for changes that will attract a larger audience.

At the same time, I don't want to see the [somewhat limited] developer 
resources devoted to fixing problems that don't exist or to providing 
solutions that, in the end, no one will use.

The Java bridge almost falls into the latter category -- almost in that 
there are a handful of developers that have either stuck with it or 
need to use it to access Java only functionality.

If you look at the cocoa-dev mailing list archive, there is a boatload 
of posts from people that started with the Java/Cocoa APIs, worked with 
it for a while, and either gave up or picked up ObjC.  Of those that 
picked up ObjC, they have become some of the most vocal proponents of 
the language!

There are really two problems here:  One of marketing, one of a 
technical nature.

On the marketing side, if providing a layer on top of the existing 
PyObjC system will make it more palatable to a larger degree of Python 
programmers, there is certainly value within doing so!

I do feel strongly that most programmers that come through this route 
will eventually find themselves using the '_' notation more and more 
often for three key reason;  it immediately indicates where the bridge 
is crossed (which, regardless of the transparency of the bridge, that 
the bridge has been crossed is important), reduces maintenance costs 
over time, and provides the maximum interoperability between Python and 
ObjC with the least amount of effort.

On the technical side... well, you know my feelings on the technical 
side -- that has been what the thread has focused on!

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Jack J. <Jac...@or...>]

On woensdag, oktober 16, 2002, at 05:34 , bb...@ma... wrote:
> We have been down this path a number of times over the six year 
> history of the PyObjC module.  In all cases, we have ended up 
> back with the naming conventions that we have now for a number 
> of reasons.   Moving from double underbar to single underbar 
> was definitely a win -- made the code easier to read and write.

I'm not convinced yet, but you're getting there:-)

You're getting there because you have by far the most experience 
with this beast, so if you say the _ convention is A Good Thing 
and everything else leads to madness: okay, proof by 
authority:-) Also, the point of ObjC-Cocoa programmers moving to 
Python is a valid one.

I'm not convinced yet, though, because I think it depends on the 
target audience. My first impression when I saw PyObjC code 
(about 18 months ago) was "UGLY!! UGLY!! UGLY!!", and I 
immediately stayed away from it for a year. And I've heard of 
more people with this reaction. So, if we care about winning 
existing Python programmers over to Cocoa (which I think we 
should: even though Carbon is going to be around for a long time 
it'll only be interesting to existing Mac programmers, and Cocoa 
has the potential to win over unix and windows Python people) we 
should make sure it looks appealing.

Let's try for a political solution. The official mapping is 
the _ mapping. However, for convenience there are some method 
names that have an alias. This alias is translated early on 
(when looking up the method name from Python, or when creating 
the Python subclass of an ObjC class), and the official name is 
used from then on. Would this be workable?
--
- Jack Jansen        <Jac...@or...>        
http://www.cwi.nl/~jack -
- If I can't dance I don't want to be part of your revolution -- 
Emma Goldman -

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Wednesday, October 16, 2002, at 06:10 PM, Bob Ippolito wrote:
> It's not.  Though, I can see how it'd be kinda useful in strange cases 
> to have the "rt.call" function around.

Definitely useful!

In particular, if we had an objc_msgSend() equivalent available on the 
Python side of the bridge, it opens things up for some truly tremendous 
opportunities.

(If you know ahead of time the type and number of arguments -- which 
you would given that the call is coming from Python -- then 
NSInvocation can be used to build a stack frame and, as such, could be 
used to implement a solution -- slightly inefficient, but a solution 
none-the-less)

With objc_msgSend() around, you could do something like...

     objc.msgSend(Foundation.NSString, "stringWithFormat:", "Foo %d Bar 
%5.3f Baz %s", 10, 25.3, "bob")

That is, you could call the handful of varargs methods in the various 
'kits.

But, more importantly, it means that you could programmatically 
dispatch methods from the python side using standard idioms -- 
something that *can* be done now, but not without a bit of pain.

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bob I. <bo...@re...>]

On Wednesday, Oct 16, 2002, at 17:45 America/New_York, bb...@ma... 
wrote:
>>
>> That's not a case of ambiguity, that's just Programmer Error.  
>> Unknown selector is what they *should* get for issuing the selectors 
>> in an incorrect order.  Notice that he's using ordered list 
>> arguments, not dictionary arguments for his call function.
>
> In that you are correct -- an array of arguments could be interpreted 
> in this fashion.
>
> However, I completely fail to see how...
>
>     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>
> ... is cleaner/clearer/better than...
>
>     obj.drawSelfAtPoint_color_withSize_(p, c, s)

It's not.  Though, I can see how it'd be kinda useful in strange cases 
to have the "rt.call" function around.

-bob

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

On Wednesday, October 16, 2002, at 05:27 PM, Bob Ippolito wrote:
>> rt.call() concatenates the method name as "drawSelfAtPoint: color:  
>> withSize:". Then the runtime sends a message to the object to perform  
>> the selector "@sel (drawSelfAtPoint: color: withSize:)", and the  
>> object says, it can't.

The two are identical in the context of @selector(), but not  
NSSelectorFromString.   Odd.  A bugreport.apple.com report has been  
filed.

Consider this output:

2002-10-16 17:42:19.198 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: ==  
pathForResource:ofType:inDirectory:forLocalization:
2002-10-16 17:42:19.232 bar[9636]  
pathForResource:ofType:inDirectory:forLocalization: != pathForResource:  
ofType: inDirectory: forLocalization:

 From this code:

#import <Foundation/Foundation.h>

int main (int argc, const char * argv[]) {
   NSAutoreleasePool * pool = [[NSAutoreleasePool alloc] init];
   SEL sel1 =  
@selector(pathForResource:ofType:inDirectory:forLocalization:);
   SEL sel2 = @selector(pathForResource: ofType: inDirectory:  
forLocalization: );

   SEL sel3 =  
NSSelectorFromString(@"pathForResource:ofType:inDirectory:forLocalizatio 
n:");
   SEL sel4 = NSSelectorFromString(@"pathForResource: ofType:  
inDirectory: forLocalization: ");
   if (sel1 == sel2)
     NSLog(@"%@ == %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel1),  
NSStringFromSelector(sel2));

   if (sel3 == sel4)
     NSLog(@"%@ == %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   else
     NSLog(@"%@ != %@", NSStringFromSelector(sel3),  
NSStringFromSelector(sel4));
   [pool release];
   return 0;
}

Seems like a bit of a discontinuity between the way the two work.

>>
>> Am I understanding you correctly? Because, the way I see it, this is  
>> likely to encourage runtime errors (unknown selector).
>
> That's not a case of ambiguity, that's just Programmer Error.  Unknown  
> selector is what they *should* get for issuing the selectors in an  
> incorrect order.  Notice that he's using ordered list arguments, not  
> dictionary arguments for his call function.

In that you are correct -- an array of arguments could be interpreted  
in this fashion.

However, I completely fail to see how...

     rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")

... is cleaner/clearer/better than...

     obj.drawSelfAtPoint_color_withSize_(p, c, s)

b.bum

[Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[tmk <li...@ne...>]

Yo,

FWIW, after reading all the proposals re: the method syntax. and 
writing some (a little) Python Cocoa code, I'm getting the strong 
feeling that I'd definitely go for bbum's suggestion to stay with the 
current "_" based naming convention.

> object.message_withFoo_(arg1, arg2)

It may not be the prettiest but after some testing, this syntax proved 
to be the easiest-to-understand and to map CORRECTLY with its ObjC 
counterparts (e.g. when I read.messageWithFoo(arg1, arg2) I found that 
I tend to expect only one argument (withFoo) while the underscore make 
it clear there are two of them and in what order).

Besides I remember how the ObjC syntax eventually made sense to me. It 
was after I read the following recipe:

"there are as many parameters to a message as they are colons in its 
name".

My litmus test for the syntax choice: "explain the mapping mechanism 
unambiguously in one sentence".

"replace the underscores in the python method name by colons and you'll 
get the name of the original ObjC method"

(Btw, is this the reason why there's hardly any doc with the PyObjC 
0.7.0 package ;-)

Wow. And again so many thanks and kudos to Ronald, Bill et al for this 
incredible tool.

Today I wrote my first real Cocoa app (other than those in the 
tutorials I've read) in python in a couple of hours.

This is all IMHO and just my .02 euros.

= tmk =


On Wednesday, Oct 16, 2002, at 10:54 Europe/Brussels, Jack Jansen wrote:

>
> On Wednesday, October 16, 2002, at 09:45 , Just van Rossum wrote:
>
>> Seth Delackner wrote:
>>
>>> To expand on my previous comment in a different direction, why not:
>>>
>>> rt = pyobjc.runtime
>>>
>>> rt.call(obj, "message", "arg1name", arg1value, "arg2name", 
>>> arg2value);
>>> Which would directly map to:
>>> [obj message arg1name:arg1value arg2name:arg2value];
>>> although I'll be the first to admit I have no idea how to actually
>>> affect that transform.
>>
>> I still know very little about ObjC, let alone pyobjc, but in my 
>> ideal would be
>> something like:
>>
>>   obj.message(arg1name=arg1value, arg2name=arg2value)
>
> There's a fundamental problem with this: the "argnames" are really 
> part of the Objective C method name. I.e. if you see  a call [object 
> message: arg1 withFoo: arg2] you should think of "message:withFoo:" as 
> the method name, *not* of "message:" as the message name and 
> "withFoo:" as the name of an optional argument.
>
> Within the ObjC environment the three methods [object message], 
> [object message: arg1] and [object message: arg1 withFoo: arg2] have 
> absolutely no relationship to each other. Trying to unify these is 
> going to lead to some very ugly code at some point. For instance, how 
> would you override "message:withFoo:" in a Python object subclassed 
> from an ObjC object without overriding "message:"?
>
> ObjC picked the "interspersed method names" (there's probably an 
> official term for this) up from Smalltalk. And, incidentally, ABC, 
> Python's predecessor, had this same syntax but it's one of the many 
> things from ABC that Guido dropped for Python.
>
> Something that is open to discussion, I think, is how to map ObjC 
> names to Python names. The current PyObjC code supports two 
> compile-time options, object.message_withFoo_(arg1, arg2) and another 
> that I forget with even more underscores in there (this mapping is 
> ambiguous: it maps to both [object message: withFoo:] and to [object 
> message_withFoo:]). The Java-ObjC brigde has simply defined sensible 
> static mappings for all names used in Cocoa, and the above would 
> probably become something like object.messagewithFoo() or 
> object.messageWithFoo(). Python's current method is more flexible, but 
> boy does it lead to ugly method names in your code...
> --
> - Jack Jansen        <Jac...@or...>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>
>
> _______________________________________________
> Pythonmac-SIG maillist  -  Pyt...@py...
> http://mail.python.org/mailman/listinfo/pythonmac-sig
>

[Pyobjc-dev] How to do isKindOfClass:? (and a bug fix)

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

The NSStringFromClass() function in Foundation was misnamed as 
NSClassFromString() -- breaking the original implementation of that 
function.  Fixed.

I added a propertyListFromPythonCollection() function to the 
Foundation.   It is just a copy/paste of what was previously committed 
in the example.

I was going to go ahead and write the obvious 
pythonCollectionFromPropertyList() function, but ran into a problem.

[bumbox:~/bbum-developer/sourceforge/pyobjc] bbum% python
Python 2.2 (#1, 07/14/02, 23:25:09)
[GCC Apple cpp-precomp 6.14] on darwin
Type "help", "copyright", "credits" or "license" for more information.
 >>> from Foundation import *
 >>> mD = NSMutableDictionary.dictionary()
 >>> mD
<NSCFDictionary objective-c instance 0x161cf0>
 >>> mD.__class__
<objective-c class NSCFDictionary at 0x8db130>
 >>> mD.isKindOfClass_(NSClassFromString("NSDictionary"))
0
 >>> NSClassFromString("NSDictionary")
<objective-c class NSDictionary at 0x82f3b0>
 >>> mD.isKindOfClass_("NSDictionary")
Traceback (most recent call last):
   File "<stdin>", line 1, in ?
TypeError: expected a ObjC class or None for argument 1: its typespec 
is '#'
 >>> mD.isKindOfClass_(NSDictionary)
0
 >>> NSDictionary
<objective-c class NSDictionary at 0x82f3b0>

(If you are running the unpatched version of PyObjC, you'll need to use 
lookup_class, not NSClassFromString()).

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bob I. <bo...@ma...>]

On Wednesday, Oct 16, 2002, at 16:20 America/New_York, Bob Savage wrote:

>
> On Wednesday, October 16, 2002, at 01:54 PM, Seth Delackner wrote:
>
>> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>>
>>> [obj message: arg1 withFoo: arg2];
>>> [obj withFoo:arg2 message:arg1];
>>>
>>> Those are two different methods. This means that the Seth's system 
>>> would not work
>
>> I may be wrong, but I disagree with your assessment.  There is only a 
>> single mapping possible from my example (although now looking at it, 
>> my example had a typo).  What I meant is:
>>
>> rt.call(obj, "message", arg1, "arg2name", arg2);
>> # giving us the message name = "message:arg1name:arg2name"
>>
>> The method 'rt.call' would take arguments  [0] object to receive the 
>> message, [1] first part of the message name, [2] .  Each subsequent 
>> pair of arguments is interpreted as first the next chunk of the 
>> message name and then the next part of the message arguments.
>>
>> Where is the ambiguity?
>
> Hopefully I am not misunderstanding you. If what you are saying is you 
> could take :
>   rt.call(obj, "message", arg1, "arg2name", arg2);
> and have rt.call() concatenate the strings  "message" and "arg2name" 
> (with a colon between) then converting that to  the selector (like 
> method name for the runtime) "@sel(message: arg2name)" and then do a 
> call selector with arg1 and arg2, sure you can do that.
>
> Here is where I see the ambiguity arising:
>
> @sel is drawSelfAtPoint:withSize:color:
>
> rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")
>
> rt.call() concatenates the method name as "drawSelfAtPoint: color: 
> withSize:". Then the runtime sends a message to the object to perform 
> the selector "@sel (drawSelfAtPoint: color: withSize:)", and the 
> object says, it can't.
>
> Am I understanding you correctly? Because, the way I see it, this is 
> likely to encourage runtime errors (unknown selector).

That's not a case of ambiguity, that's just Programmer Error.  Unknown 
selector is what they *should* get for issuing the selectors in an 
incorrect order.  Notice that he's using ordered list arguments, not 
dictionary arguments for his call function.

-bob

Re: [Pyobjc-dev] exception handling design pattern

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

On Wednesday, October 16, 2002, at 03:31 PM, Ronald Oussoren wrote:
> On Wednesday, Oct 16, 2002, at 16:27 Europe/Amsterdam, Bill Bumgarner 
> wrote:
>> On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote:
>>> On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
>>> wrote:
>>>> Looking at the implementation, it looks like the problem lies in 
>>>> the behavior of the ObjC->Python part of the bridge in that it 
>>>> leaves the NSException in a wrapped up state?
>>> That's right. I never got around to implement this, adding this code 
>>> should be relatively straightforward. I'll look into it.
>>
>> Thanks.   It isn't a huge issue, but anything that makes the bridge 
>> more transparent is definitely a boon.
> I've just checked in a fix. Forwarding exceptions in the 'other' 
> runtime is now cleaner, and when the exception travels back into its 
> own runtime it regains its original identity.

Excellent!!

> There is one thing I have not really looked into yet: What is the 
> normal way of processing exceptions in Objective-C, do you use '==' or 
> 'isEqual' to check if the exception is one you can handle? If it is 
> the former some additional work is necessary: NSString objects are 
> transparently translated into Python strings and Python strings are 
> translated in (freshly allocated) NSStrings. Thus when you trow 
> NSSomeException from Python it is 'isEqual' on the Objective-C side 
> but not '=='.

It is generally done via isEqualToString: on the -name and, as such, 
shouldn't be a problem in properly written code.

>
>> BTW:  The bridge is working *really* well.  I'm using it in a 
>> production development setting and have had 0 problems other than of 
>> my own making (the exception issue wasn't a big deal).
> Wow, I can debug without a real testsuite :-)

Speaking of:  I would eventually like to toss together a python-esque 
test suite for PyObjC that is included with the distribution.

In the case of exceptions, I simply switched to using:

     raise NSInternalInconsistencyException, "Something really, really 
bad happened."

Other than the lack of a userInfo dictionary into which I occasionally 
carry along some meta info, this works fine.  Now that I can toss 
proper Obj-C exceptions, this limitation can go away, as well.

Though -- thinking it through -- likely continuing with the raise style 
pure-python exception is the way to go if the bridge converts it 
correctly.  I just wish there was a way to carry along meta info.

>>> BTW. I've been playing with libffi and I'm pretty sure it can be 
>>> used to remove the need for the register.m file. I already have a 
>>> function that returns an 'IMP' for in the Objective-C method 
>>> dispatch table (given a method signature). I can't test this at the 
>>> moment because libffi refused to build into a shared library...
>>
>> If the inclusion of a shared library requires end users of standalone 
>> applications to go through some kind of installation process to have 
>> the shlib dumped off in the proper location, I will be very strongly 
>> against the inclusion of features that require a shared library.
>
> I agree, if I get this into a usable shape libffi should be linked 
> into the objc._objc module (no seperate shared library). An external 
> library should also never be required for using PyObjC, we should keep 
> the current mechanism.

Definitely on the same page there!  Good!

> The problem I'm currently having is that one of the source files won't 
> compile into an object file that can be used in a dynamicly loaded 
> object.

What is the problem?  I have tangled with these issues in the past.

b.bum

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bob S. <bob...@ma...>]

On Wednesday, October 16, 2002, at 01:54 PM, Seth Delackner wrote:

> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods. This means that the Seth's system 
>> would not work

> I may be wrong, but I disagree with your assessment.  There is only a 
> single mapping possible from my example (although now looking at it, 
> my example had a typo).  What I meant is:
>
> rt.call(obj, "message", arg1, "arg2name", arg2);
> # giving us the message name = "message:arg1name:arg2name"
>
> The method 'rt.call' would take arguments  [0] object to receive the 
> message, [1] first part of the message name, [2] .  Each subsequent 
> pair of arguments is interpreted as first the next chunk of the 
> message name and then the next part of the message arguments.
>
> Where is the ambiguity?

Hopefully I am not misunderstanding you. If what you are saying is you 
could take :
   rt.call(obj, "message", arg1, "arg2name", arg2);
and have rt.call() concatenate the strings  "message" and "arg2name" 
(with a colon between) then converting that to  the selector (like 
method name for the runtime) "@sel(message: arg2name)" and then do a 
call selector with arg1 and arg2, sure you can do that.

Here is where I see the ambiguity arising:

@sel is drawSelfAtPoint:withSize:color:

rt.call(obj, "drawSelfAtPoint", p, "color", c, "withSize", "s")

rt.call() concatenates the method name as "drawSelfAtPoint: color: 
withSize:". Then the runtime sends a message to the object to perform 
the selector "@sel (drawSelfAtPoint: color: withSize:)", and the object 
says, it can't.

Am I understanding you correctly? Because, the way I see it, this is 
likely to encourage runtime errors (unknown selector).

Bob

Re: [Pyobjc-dev] exception handling design pattern

[Ronald O. <ous...@ci...>]

On Wednesday, Oct 16, 2002, at 16:27 Europe/Amsterdam, Bill Bumgarner 
wrote:

> On Wednesday, October 16, 2002, at 02:42 AM, Ronald Oussoren wrote:
>> On Tuesday, Oct 15, 2002, at 23:53 Europe/Amsterdam, Bill Bumgarner 
>> wrote:
>>> Looking at the implementation, it looks like the problem lies in the 
>>> behavior of the ObjC->Python part of the bridge in that it leaves 
>>> the NSException in a wrapped up state?
>> That's right. I never got around to implement this, adding this code 
>> should be relatively straightforward. I'll look into it.
>
> Thanks.   It isn't a huge issue, but anything that makes the bridge 
> more transparent is definitely a boon.
I've just checked in a fix. Forwarding exceptions in the 'other' 
runtime is now cleaner, and when the exception travels back into its 
own runtime it regains its original identity.

There is one thing I have not really looked into yet: What is the 
normal way of processing exceptions in Objective-C, do you use '==' or 
'isEqual' to check if the exception is one you can handle? If it is the 
former some additional work is necessary: NSString objects are 
transparently translated into Python strings and Python strings are 
translated in (freshly allocated) NSStrings. Thus when you trow 
NSSomeException from Python it is 'isEqual' on the Objective-C side but 
not '=='.

> BTW:  The bridge is working *really* well.  I'm using it in a 
> production development setting and have had 0 problems other than of 
> my own making (the exception issue wasn't a big deal).
Wow, I can debug without a real testsuite :-)

>
>> BTW. I've been playing with libffi and I'm pretty sure it can be used 
>> to remove the need for the register.m file. I already have a function 
>> that returns an 'IMP' for in the Objective-C method dispatch table 
>> (given a method signature). I can't test this at the moment because 
>> libffi refused to build into a shared library...
>
> If the inclusion of a shared library requires end users of standalone 
> applications to go through some kind of installation process to have 
> the shlib dumped off in the proper location, I will be very strongly 
> against the inclusion of features that require a shared library.

I agree, if I get this into a usable shape libffi should be linked into 
the objc._objc module (no seperate shared library). An external library 
should also never be required for using PyObjC, we should keep the 
current mechanism.

The problem I'm currently having is that one of the source files won't 
compile into an object file that can be used in a dynamicly loaded 
object.
>
> The value of the PyObjC bridge is primarily that it can be used so 
> transparently within the X environment.    At this point, the PyObJC 
> is considerably more straightforward to use than the Java-ObjC bridge 
> and is easier to use than the AppleScript Studio bridge.
>
> Anything that takes away from that transparency must have a huge 
> return on investment to be worth it.
>
<nod>

> With all that said, eliminating the register.m based dispatch would 
> certainly be a win.   Did you receive my earlier message regarding 
> method dispatch within the Java<->ObjC bridge?   It was able to do its 
> thing without requiring a mapping for every method and without 
> something like the register.m functionality.

I did receive you earlier message, but didn't use that information at 
the time.

The description in your mail sounds a bit like OC_PythonObject in 
PyObjC, but not quite. You wouldn't have a pointer to more information, 
would you?

I ran 'bridget' on '/Developer/Java/Jobs/Foundation.jobs' and looked at 
the results. This tool generates java classes with lots of 'native' 
methods. The implementation of these methods call into Objective-C 
using objc_msgSendSuper (like the super_N functions in register.m). At 
least this explains why you can do 'super.method()' in subclasses of 
Java proxies.

 From what I see in the header files, message passing from Objective-C 
to Java is  done through an NSProxy-style class, like you already wrote.

This is a bit like I expected. The problem with 'objc_msgSendSuper' is 
that there is no version of it that accepts a 'va_list' type argument 
(like objc_msgSendv) which means you can only generate calls to 
objc_msgSendSuper by manually building a stack-frame (or by using a 
library that does this for you).

BTW. Whoever wrote bridget is quite fond of CPP, making sense of the 
layers of macros was quite an adventure :-)

Ronald

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Ted H. <Ted...@ub...>]

I apologize for low content ratio of this post, but as a once and  
(hopefully) future heavy user of the pyobjc bridge, I just wanted to  
whole-heartedly agree with everything that Bill says in this post.  Explicit  
and straightforward are the way to go.

Now that I've delurked temporarily, I also want to take this opportunity to  
extend a huge thanks to Ronald and Bill for their work on this project.  I  
am really looking forward to getting back to this kind of environment.

On Wed, 16 Oct 2002, bb...@ma... wrote:
> (Jack;  thanks for the CC to pyobjc.  I have now subscribed to
> pythonmac and will try to keep up with things in this SIG.)
>
> First, a brief update on the progress made on the PyObjC project.
>
> The module itself is now compatible with the Apple supplied build of
> Python 2.2.
>
> At this point, the developer can create a new project in Project
> Builder, select "Cocoa-Python Application" (a custom template included
> with PyObjC), and Project Builder will create a new Cocoa application
> project that is implemented entirely in Python.  The project template
> includes an implementation for a basic application delegate (NSObject
> subclass) that includes target/actions, outlets, and notification
> handling.
>
> When the 'install' target is used, the resulting application runs
> completely standalone on any OS X 10.2 machine without requiring that
> the user has preinstalled PyObjC or a custom build of Python.
>
> In comparison to Cocoa-Java, the PyObjC bridge is significantly less
> intrusive.   More on this below.
>
> In comparison to Cocoa-AppleScript (AppleScript Studio), the PyObjC
> bridge presents a development experience that is much closer to pure
> Cocoa.  AppleScript Studio is really a mix of Cocoa widgets into
> AppleScript style event handling-- the end result is very powerful, but
> it isn't Cooca programming.
>
> At this point, the PyObjC bridge is being used in several production
> quality projects/products.  I.e. it is working now and working
> extremely well!!
>
> (And, again, a huge note of thanks to Ronald -- his work on the
> subclassing and method dispatch mechanisms made it all possible.)
>
> More information interspersed with Jack's and Ronald's text below.
>
> On Wednesday, October 16, 2002, at 09:17 AM, Jack Jansen wrote:
> > [I've added pyobjc-dev to the distribution]
> > On Wednesday, October 16, 2002, at 02:28 , Ronald Oussoren wrote:
> >>> Something that is open to discussion, I think, is how to map ObjC
> >>> names to Python names. The current PyObjC code supports two
> >>> compile-time options, object.message_withFoo_(arg1, arg2) and
> >>> another that I forget with even more underscores in there (this
> >>> mapping is ambiguous: it maps to both [object message: withFoo:] and
> >>> to [object message_withFoo:]). The Java-ObjC brigde has simply
> >>> defined sensible static mappings for all names used in Cocoa, and
> >>> the above would probably become something like
> >>> object.messagewithFoo() or object.messageWithFoo(). Python's current
> >>> method is more flexible, but boy does it lead to ugly method names
> >>> in your code...
> >>
> >> Changing the mapping from Objective-C names to/from Python names is
> >> definitely open for discusion.
> >>
> >> BTW. The current PyObjC no longer supports object.message__withFoo__.
>
> We have been down this path a number of times over the six year history
> of the PyObjC module.  In all cases, we have ended up back with the
> naming conventions that we have now for a number of reasons.   Moving
> from double underbar to single underbar was definitely a win -- made
> the code easier to read and write.
>
> > I think that what I would like is one static scheme that is the same
> > (or almost the same) as the Java/ObjC naming scheme, plus a fallback
> > scheme (which could be the current message_withFoo_ scheme). There may
> > be a problem here with overloading, though: if I look at AppKitJava
> > there's often multiple ObjC selectors that map to one Java method
> > name, I'm not sure how they handle this, especially in the face of
> > overriding ObjC methods from Java.
>
> The key value in the PyObjC module is that it provides an ObjC
> development experience that is about as close to transparent as can be
> achieved when mapping from one language to another.   One of the most
> frustrating aspects of doing ObjC/Java (the bridge existed back to
> WebObjects 3.0 in 1997) was because of the mapping of method names.
> Specifically, the developer effectively had to learn three APIs deeply
> to be effective -- the ObjC API, the Java SDK APIs, and this weird
> permutation of the ObjC APIs as presented in Java.
>
> End result;  the developer is constantly frustrated by constantly
> having to do the mapping in their heads.  Worse, the mapped
> representation -- the conversion from, say, setObject:forKey: to
> setObjectForKey() -- loses the emphasis on the number and order of
> parameters that is emphasized by ObjC's method naming scheme.
>
> From personal experience-- both as a developer and a WebObjects
> training instructor-- I can confidently say that all of the effort that
> was put into presenting the ObjC API in Java such that it appeared to
> be a Java API caused a hell of a lot more confusion than it ever
> perpetuated clarity!
>
> Even if it slightly less Python-Pretty, this...
>
> mutableDictionary.setObject_forKey_ ( "foo", "bar" )
>
> ... is ultimately easier to read and maintain than this...
>
> mutableDictionary.setObjectForKey( "foo", "bar" )
>
> ... for a number of reasons:
>
> - the first is immediately recognizable as an ObjC method call.
> Regardless of how transparent the bridge is, the bridge is there and it
> does affect behavior.  Trying to hide it makes maintenance
> significantly more expensive and the introduction of new developers
> into a project harder.  (I helped maintain a mixed ObjC<->Java codebase
> with 500,000+ lines of code for over 3 years.   The bridge was the
> single largest cause of problems in the project -- that it tried to
> hide the "crossing of the bridge" just confused things.)
>
> - the first form preserves the argumentation information as
> provided by the traditional ObjC method name (setObject:forKey:)-- the
> developer can easily map between that syntax and the original ObjC
> method.  The second loses that information and the developer can easily
> assume that the key should be first.   This is a huge problem among my
> development team with WebObjects 5.x -- all of us make this kind of
> mistake on a regular basis.
>
> - the first has the distinct advantage of allowing the developer to
> *always* be able to deduce the original ObjC method name by simply
> looking at the code.  The developer doesn't have to go follow some
> random mapping to try and figure out what the ObjC method's name
> originally was.
>
> > Hmm, even if that isn't possible we could cop out: if the method name
> > translation routine finds that a certain name isn't in the
> > dictionaries it would simply add it. Or (more cumbersome, but safer)
> > there could be a (Python) API MapObjCSelector('message:withFoo',
> > 'messageWithFoo') which could then also check that this mapping
> > doesn't conflict with another one. With such a scheme the Python
> > programmer would have to declare any new ObjC messages it uses, but
> > the question is how often this will happen.
>
> Anything that adds more steps to the bridging process is bad.  One of
> the most powerful and valuable aspects of the PyObjC bridge is that it
> so totally transparent;  much more so than CamlBones (doesn't do
> subclassing), Java<->ObJC (changes the API) and AppleScript<->ObjC (not
> intended to be transparent at all).
>
> The developer is going to be defining new ObjC methods quite often.
> The current PyObjC module can complete replace ObjC within a Cocoa
> project.  That is, Python is used to create all of the custom classes
> that one would normally find in a Cocoa project.   As such, the
> developer is writing lots of custom methods that implement the
> functionality specific to their application.   Certainly, there are
> many cases where the developer is simply overriding existing Cocoa
> providing functionality.
>
> As it is, many of those methods have to be declared such that the
> bridge can figure out how to do the dispatch.   Very unfortunate, in
> and of itself, but livable.   It would be even more unfortunate if
> every single action method and other custom methods had to be declared,
> as well!
>
> b.bum
>

Visit our website at http://www.ubswarburg.com

This message contains confidential information and is intended only 
for the individual named.  If you are not the named addressee you 
should not disseminate, distribute or copy this e-mail.  Please 
notify the sender immediately by e-mail if you have received this 
e-mail by mistake and delete this e-mail from your system.

E-mail transmission cannot be guaranteed to be secure or error-free 
as information could be intercepted, corrupted, lost, destroyed, 
arrive late or incomplete, or contain viruses.  The sender therefore 
does not accept liability for any errors or omissions in the contents 
of this message which arise as a result of e-mail transmission.  If 
verification is required please request a hard-copy version.  This 
message is provided for informational purposes and should not be 
construed as a solicitation or offer to buy or sell any securities or 
related financial instruments.

Re: [Pyobjc-dev] Re: pyobj-c bridge questions

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

The project builder template has been updated and committed.  I should 
also update the installer package at some point.  Yuck.

b.bum

On Wednesday, October 16, 2002, at 02:50 PM, Bill Bumgarner wrote:
> I'll update the Project Builder template to reflect the new code.

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Bob I. <bo...@ma...>]

On Wednesday, Oct 16, 2002, at 14:54 America/New_York, Seth Delackner 
wrote:

> On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
>> I just want to point out one more thing: because these are part of 
>> the name of the method, and not truly labels, the following two 
>> methods are distinct:
>>
>> [obj message: arg1 withFoo: arg2];
>> [obj withFoo:arg2 message:arg1];
>>
>> Those are two different methods. This means that the Seth's system 
>> would not work at all (although I don't like it because it makes the 
>> relation between the 'labels' and arguments less clear).
>
> I may be wrong, but I disagree with your assessment.  There is only a 
> single mapping possible from my example (although now looking at it, 
> my example had a typo).  What I meant is:
>
> rt.call(obj, "message", arg1, "arg2name", arg2);
> # giving us the message name = "message:arg1name:arg2name"
>
> The method 'rt.call' would take arguments  [0] object to receive the 
> message, [1] first part of the message name, [2] .  Each subsequent 
> pair of arguments is interpreted as first the next chunk of the 
> message name and then the next part of the message arguments.
>
> Where is the ambiguity?  Also, since obj is really a python wrapper 
> class for Objective-C objects, one could probably make 'call' a method 
> (renamed to avoid conflicts) on the wrapper class, resulting in 
> something like:
>
> obj._call("message", arg1, "arg2name", arg2);

Surely you _could_ do something like this, relatively easily at that, 
but with this method you can't do any subclassing.

-bob

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[Seth D. <se...@jt...>]

On Wednesday, October 16, 2002, at 06:18 , Bob Savage wrote:
> I just want to point out one more thing: because these are part of the 
> name of the method, and not truly labels, the following two methods are 
> distinct:
>
> [obj message: arg1 withFoo: arg2];
> [obj withFoo:arg2 message:arg1];
>
> Those are two different methods. This means that the Seth's system 
> would not work at all (although I don't like it because it makes the 
> relation between the 'labels' and arguments less clear).

I may be wrong, but I disagree with your assessment.  There is only a 
single mapping possible from my example (although now looking at it, my 
example had a typo).  What I meant is:

rt.call(obj, "message", arg1, "arg2name", arg2);
# giving us the message name = "message:arg1name:arg2name"

The method 'rt.call' would take arguments  [0] object to receive the 
message, [1] first part of the message name, [2] .  Each subsequent pair 
of arguments is interpreted as first the next chunk of the message name 
and then the next part of the message arguments.

Where is the ambiguity?  Also, since obj is really a python wrapper 
class for Objective-C objects, one could probably make 'call' a method 
(renamed to avoid conflicts) on the wrapper class, resulting in 
something like:

obj._call("message", arg1, "arg2name", arg2);

[Pyobjc-dev] Re: pyobj-c bridge questions

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

You are correct.  It is very wrong.  I fixed this problem and several 
others in the main [and currently proprietary] project that I'm working 
on that uses the bridge, I just hadn't had a chance to migrate the code 
back into the bridge.

I apologize for the inconvenience.

If you grab the latest code from the CVS repository, the Web Services 
Tool example has been updated appropriately to reflect the new 
implementation.  Of note:

     - I changed memory management semantics.  Namely, the main() 
function no longer releases anything.  It isn't necessary.  As soon as 
the call to execve() is made, the original process is completely 
destroyed.

     - I fixed the bug that Joe so graciously pointed out.

     - The main() function now walks the list of frameworks that are 
linked into the command line executable and creates an argument to the 
python interpreter that lists all of the frameworks.

     - The argument used in the previous step is used by the Main.py 
file to automatically load all frameworks that were linked into the 
original bootstrapper.   As well, if any of the frameworks have an 
"Init.py" file in their resources, it is executed.

The end result is that mixing in compiled ObjC classes into your 
PyCocoa application is as easy as adding a framework target to your 
project and linking it into the target that compiles bin-python-main.m.

(Of interest -- the proprietary project I'm working on is a custom 
Cocoa XML-RPC client to www.intentcenter.com.  It uses Python to do all 
of the server interaction and a slew of Cocoa classes to implement the 
UI.   The Python code is replacing an initial implementation against 
the CoreWebServices framework.  By moving to Python with PyObjC, I have 
been able to cut something like 1,000 lines of really gnarly C code 
while greatly improving the quality of implementation/interaction with 
the server.)

I'll update the Project Builder template to reflect the new code.

b.bum

On Wednesday, October 16, 2002, at 02:24 PM, Joseph Grace wrote:

> Hi Bill:
>
> Thank you for the bridge.  If you're too busy to answer a couple of 
> curiosity questions, I understand.  On the chance that these are 
> quickies, here goes...
>
> 1.  I am curious about the code in main-bin-python.m.  Is it really 
> supposed to be:
>
>   childArgv[0] = argv[0];
>   childArgv[1] = mainPyPathPtr;
>   for (i = 1; i<argc; i++)
>     childArgv[i+2] = argv[i];
>   childArgv[i+2] = NULL;
>
> My logic tells me it should rather be:
>
>   childArgv[0] = argv[0];
>   childArgv[1] = mainPyPathPtr;
>   for (i = 1; i<argc; i++)
>     childArgv[i+1] = argv[i];    //  i+2 becomes i+1?
>   childArgv[i+2] = NULL;
>
> ?  I'm not very confident though, so I thought I would mention it (in 
> case it is a minor bug), or perhaps learn something so the code makes 
> sense to me.
>
> 2.  I am trying to rebuild the project (so I could test my theory 
> about the bug, above, and just generally be able to use the code) and 
> am getting an error: "Error from Debugger: mi_cmd_stack_list_frames: 
> Not enough frames in stack."  Is there any trick to debugging or 
> building the project?
>
> Excellent work (I'll love it to learn Cocoa from python :-).  I look 
> forward to understanding how you work the magic, and how to use python 
> anc Cocoa.
>
> Cheers,
>
> = Joe =
>
>
b.bum
I ride tandem with the random....
	.... things don't run the way I planned them.

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

This is exactly what the Java bridge does and it is a huge source of 
confusion and bugs.   Most developers assume that it should be (key, 
value), not (value, key) -- even developers that have spent years with 
the ObjC version of the Foundation.

In teaching WebObjects classes, I spent a very good part of my "walk 
around the room and help students" time fixing problems that were 
related to this kind of mapping across the bridge (or, in the case of 
pure Java version of WO, the implicit mapping as a result of the pure 
Java rewrite).

The Objective-C APIs were very carefully designed over many years 
(starting in 1986).  The vocabulary used by those APIs leverage the 
syntax of the language (and of languages like it -- see SmallTalk).   
Attempting to map that vocabulary straight to Java or Python results in 
a new API whose vocabulary is incomplete and confusing.

If there are situations where the existing mapping doesn't work-- that 
rare case where an '_' appears in the method name other than at the 
beginning (I grep'd through all of the headers provided by Apple and 
there isn't a single case where a '_' is used anywhere but to prefix 
the method)-- then providing a Python accessible function that is 
equivalent to objc_msgSend() will fix the problem (It will also fix a 
couple of other problems -- like how to support varargs).

b.bum

On Wednesday, October 16, 2002, at 12:26 PM, William Dozier wrote:
> This is the best suggestion I have seen yet.
> On Wednesday, Oct 16, 2002, at 09:49AM, Ronald Oussoren 
> <ous...@ci...> wrote:
>> 	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

[William D. <wdd...@ma...>]

This is the best suggestion I have seen yet. 


On Wednesday, Oct 16, 2002, at 09:49AM, Ronald Oussoren <ous...@ci...> wrote:

>	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)
>

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

This has not been my experience.

In using the bridge, I define completely new selectors on the python 
side all the time as I refractor and generalize my code.   As well, I'm 
defining new selectors as targets of Timers, Notifications, and certain 
kinds of delegation (sheet call back methods, as an example).

These all have relatively predictable signatures, but the selector 
names tend to be unique inventions of my projects.

In other words, I'm doing with the PyObjC bridge the exact same kind of 
development that I-- and the rest of the ObjC development community-- 
have done with ObjC for the last decade.

b.bum

On Wednesday, October 16, 2002, at 10:39 AM, Ronald Oussoren wrote:
> IMHO it is highly unlikely that users define completely new selectors 
> in Python, other than new actions for use in Interface Builder, and I 
> already have written a module that reads the classes.nib from a .NIB 
> 'file' and creates a python module containing the corresponding python 
> classes. Using names without underscores for IBActions is therefore 
> very easy.

Re: [Pyobjc-dev] Re: [Pythonmac-SIG] pyobjc / cocoa

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

A brief followup to my previous email:

     Doing such a mapping is ultimately a Very Bad Idea.

	While it makes reading PyObjC code easier from the perspective of a 
Python programmer, it seriously hampers the efforts of a programmer 
coming to the environment from an ObjC background.

     Making messaging across the bridge transparent is paramount.  
Making it syntactically transparent will cause problems both in 
maintenance and in coding efficiency.

     The Java bridge should not be used as a model of "how to do things 
right".  It is a painful, painful thing to use.

     As well, the pure Java version of Foundation, EO, and WebObjects 
provide a great deal of evidence that trying to map the Objective-C 
syntax into a Java or Python-like (because, in reality, Java's and 
Python's method invocation syntax is fairly identical) leads to a lot 
of confusion.   Even to this day, developers that have spent years 
working against the pure Java version of Foundation hesitate for a 
second when dealing with methods like setObjectForKey() -- some of the 
longer methods are even worse.

     As ugly as it is, there is a hell of a lot of value in preserving 
the ObjC method naming semantics on the Python side of the bridge.

     We have been down this path before -- in the ObjC [WebScript and 
its "new style" syntax] realm, in the Java realm with the bridge and 
pure Java implementations of Foundation, etc., and in the Python realm 
(this discussion has come up in the context of PyObjC on a regular 
basis since the project's inception so many years ago.

     b.bum


On Wednesday, October 16, 2002, at 11:25 AM, Jack Jansen wrote:
> On Wednesday, October 16, 2002, at 04:49 , Ronald Oussoren wrote:
>> To reply to myself...
>>
>> Another mapping scheme would be to just drop the colons and translate 
>> the character just beyond colons to uppercase. This would make the 
>> python methodnames more pleasant, although still long and 'foreign 
>> looking':
>>
>> 	[obj setObject:value forKey:key] -> obj.setObjectForKey(value, key)
>
> I think the bottom line is: which method makes it easiest to write 
> Python code given Apple's documentation? I must say I haven't looked 
> at the Java Cocoa documentation (actually, I tend to read the ObjC 
> header files mostly) but if that is good then I think we should stick 
> with the Java names. If it isn't good (or nonexistent:-) then an 
> algorithmic name translation scheme is probably best.
>
> Something else that might be worthwhile is a helper command that 
> translates ObjC calls to Python. You would then copy [obj setObject: 
> value forKey: key], paste it in your Python script (where it will stay 
> selected) and select the "ObjC methodcall to Python" command to turn 
> it into obj.setObjectForKey(value, key). The only question is how we 
> could get this into Project Builder (into the Python IDE would be 
> easy).
> --
> - Jack Jansen        <Jac...@or...>        
> http://www.cwi.nl/~jack -
> - If I can't dance I don't want to be part of your revolution -- Emma 
> Goldman -
>
>
>
> -------------------------------------------------------
> This sf.net email is sponsored by: viaVerio will pay you up to
> $1,000 for every account that you consolidate with us.
> http://ad.doubleclick.net/clk;4749864;7604308;v?
> http://www.viaverio.com/consolidator/osdn.cfm
> _______________________________________________
> Pyobjc-dev mailing list
> Pyo...@li...
> https://lists.sourceforge.net/lists/listinfo/pyobjc-dev
>
b.bum
Are you laughing?
	... they are.