pyobjc-dev — CVS commit notices go here

Re: [Pyobjc-dev] setVerbose()

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

Bill Bumgarner wrote:

> import objc
> from objc import YES, NO
> 
> .... for me, anyway.

Can't Python's True and False (in 2.3 at least) be mapped to YES and NO?

Just

[Pyobjc-dev] (void *) and the like revisited

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

Ronald asks in the top of ObjCPointer.m if there is any reason for that 
class any longer...

I don't think there is.  I believe the functionality for that class can 
be ripped out and the various random methods that need pointer types 
can be encapsulated in struct and array types.

I'm investigating doing exactly that with a bit of functionality 
wrapper around -bytes and -mutableBytes that use python array 
instances.   Unit tests first.... I'll commit if it is useful and we 
can roll back, if needed (the changes are highly isolated).

b.bum

Re: [Pyobjc-dev] setVerbose()

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

On Thursday, Jan 2, 2003, at 14:11 US/Eastern, Ronald Oussoren wrote:
> Don't do that then ;-) I really mean that, the objc module is meant to 
> be used with 'import objc' instead of 'from objc import *'.

OK -- then, it is...

import objc
from objc import YES, NO

... for me, anyway.

b.bum


b.bum
We gladly feast on those who would subdue us.

Re: [Pyobjc-dev] setVerbose()

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

On Thursday, Jan 2, 2003, at 04:48 Europe/Amsterdam, Bill Bumgarner 
wrote:

> The objc.setVerbose() "feels" like maybe it ought to be pushed down 
> into a namespace of some kind.
>
> Namely, if I do...
>
>     from objc import *

Don't do that then ;-) I really mean that, the objc module is meant to 
be used with 'import objc' instead of 'from objc import *'.


> ... then setVerbose() is defined in the local namespace.  setVerbose() 
> is a potentially fairly common, non-ObjC specific, name.
>
> Maybe prefixing all bridge specific configuration functionality with 
> pyobjc_?
>
> I.e. like objc_lookUpClass(), we have pyobjc_setVerbose()?
We have objc.lookUpClass and objc.setVerbose, 'objc.' as a prefix is 
just as much typing as 'objc_'. Adding the prefix therefore doesn't buy 
us much.

Ronald

[Pyobjc-dev] setVerbose()

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

The objc.setVerbose() "feels" like maybe it ought to be pushed down 
into a namespace of some kind.

Namely, if I do...

     from objc imoprt *

... then setVerbose() is defined in the local namespace.  setVerbose() 
is a potentially fairly common, non-ObjC specific, name.

Maybe prefixing all bridge specific configuration functionality with 
pyobjc_?

I.e. like objc_lookUpClass(), we have pyobjc_setVerbose()?

b.bum

[Pyobjc-dev] Added README to CurrencyConverter

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

I added a simple README to currency converter;  no big deal.  However, 
it is restructured text using docutils.sf.net -- see that project for 
more info.   REST is awesome and docutils makes it extremely easily 
accessible.

If no one is offended, I'm going to continue writing docs in this 
format.

b.bum

[Pyobjc-dev] NSBitmapImageRep

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

I would like to create an NSBitmapImageRep instance, grab the data 
plane pointers directly, and manipulate the pixels contained within 
directly.

This would seem to be possible if the -getDataPlans and the designated 
initializer were wrapped to deal with the (char **) types by wrapping 
'em in python string objects?

I'm not sure.

Any thoughts?

b.bum

Re: [Pyobjc-dev] unbound methods

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

On Wednesday, Jan 1, 2003, at 04:27 US/Eastern, Ronald Oussoren wrote:
> On Tuesday, Dec 31, 2002, at 17:34 Europe/Amsterdam, bb...@ma... 
> wrote:
>> On Monday, Dec 23, 2002, at 14:30 US/Eastern, Ronald Oussoren wrote:
....
> That would be nice, but not possible. It might be possible to get 
> 'Foo.foo(Foo)' working if the class method has the same signature as 
> the instance method, but that wouldn't allow overriding the class 
> method in subclasses. But all is not lost, read on ;-)
>
>>
>> ... and call the class method.  Or, maybe, you want to do...
>>
>>     Foo.foo_(aFoo)
> That would be [aFoo foo:] in Objective-C ;-). More seriously, that 
> wouldn't be usefull because the Python runtime looks for 'Foo.foo' 
> when you do 'aFoo.foo()'. This is what is causing us problems here.

No-- the intention would be that that would be the invocation of the 
Class method foo_ with aFoo as the single argument [and the Class 
object as 'self'].

>> ... where you are calling the class method and passing an instance as 
>> the argument?
>>
>> This isn't terribly clear, but I'm hoping it gets across the general 
>> idea that we should be able to support both class and instance 
>> methods that are named the same....
>>
>> One possibility would be to pass a kv argument that indicates that 
>> the class implementation should be used if there is both a class and 
>> an instance version-- i.e. Foo.foo(aFoo, useClassMethod=1)?
>>
>> But that would not allow an unbound version of the method to be 
>> obtained that is explicitly tied to class or instance...?
>
> We could mangle names of class methods, either by having a magic class 
> property for accessing class methods or by adding a prefix/postfix to 
> the methodname:
>
> * Foo.__clsmeth__.foo()
> * Foo._cls_foo()
> * Foo.foo_cls()
>
> I'd prefer the middle one given a suitable prefix: short, easily 
> remembered and not likely to ever be used as the prefix of an 
> Objective-C selector. If we go this route we should keep supporting 
> the current behaviour; NSArray.arrayWithArray_ should not be renamed 
> to NSArray._cls_arrayWithArray_, that would just be confusing. I'm not 
> sure wether we should support both naming schemes for class methods 
> that don't conflict with instance methods.

I agree that the current behavior should remain unchanged.  Rarely does 
the developer need to grab anything but a reference to the instance 
method.

In the ObjC context, we would implement something like:

- (IMP)methodForSelector:(SEL)aSelector;
+ (IMP)instanceMethodForSelector:(SEL)aSelector;

Where the first returns an instance method if invoked on an instance 
and a class method if invoked on a class (a Class object really being 
an instance of the meta object class).   The second method allows one 
to grab a reference to in instance method from a Class object.

Not very pythonic....

In the context of python, I like the idea of shoving the 'I really do 
want the class method' functionality into a "special" attribute.  It 
makes the code more readable than having to special case a prefix and 
ensures that there is no chance of namespace collision or ambiguity in 
the future.

Sure, a few more keystrokes, but that is a small price to pay to ensure 
that the code remain readable, thereby reducing confusion in a 
situation that will be used relatively infrequently but, when used, 
could confuse the heck out of a newbie.

I.e.:

NSObject.__class_methods__.description
NSObject.__instance_methods__.description

x = NSObject.new()
x.__class__.__class_methods__.description
x.__class__.__instance_methods__.description

This could be extended to provide:

x.__class__.__instance_variables__
x.__class__.__protocols__

Re: [Pyobjc-dev] PyObjC Wiki...

[Lele G. <le...@se...>]

>>>>> On Tue, 31 Dec 2002 11:44:56 -0700, Jiva DeVoe <ji...@de...> said:

    JD> Ok, it only took a week... sorry for the delay, holidays and
    JD> stuff...  Anyway, here's the URL:
    JD> http://www.devoesquared.com/pyobjc-moin.cgi?

Great! I'm a wiki fan! I even contribuited the italian messages for
MoinMoin, so... good choice! :-)

Thanx&bye,
lele.
-- 
nickname: Lele Gaifax	| Quando vivro' di quello che ho pensato ieri
real: Emanuele Gaifas	| comincero' ad aver paura di chi mi copia.
email: le...@se...	|		-- Fortunato Depero, 1929.

Re: [Pyobjc-dev] unbound methods

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

On Tuesday, Dec 31, 2002, at 17:34 Europe/Amsterdam, bb...@ma... wrote:

> On Monday, Dec 23, 2002, at 14:30 US/Eastern, Ronald Oussoren wrote:
>>>     Rethinking this, the above method call may not work in some  
>>> situations.  In particular, in class clusters it is often the case  
>>> that you generally interact with some private subclass.  For  
>>> example, NSArray.count(someArray) will not actually do what you want  
>>> because instances of NSArray are never directly instantiated-- just  
>>> private subclasses.
>>>
>>> In [6]: a = NSArray.arrayWithArray_([1,2,3,4,5])
>>> In [7]: a.count()
>>> Out[7]: 5
>>> In [8]: NSArray.count(a)
>>> --------------------------------------------------------------------- 
>>> ------
>>> ValueError                                Traceback (most recent  
>>> call last)
>>>
>>> ?
>>>
>>> ValueError: NSInvalidArgumentException - *** -count only defined for  
>>> abstract class.  Define -[NSCFArray count]!
>>>
>>
>> That's just like in 'normal' python types: If you call NSArray.count  
>> you get the count method defined by NSArray instead of the one  
>> defined by the class of your object. That is not very  
>> Objective-C-like, but this is needed to implement super(cls,  
>> self).count().
>
> Right.   However, the ability to use unbound methods is very much a  
> feature of Python that a lot of people use...
>
> Is there a way to support this a bit more cleanly/flexibly in light of  
> ObjC's ability to have a class method and an instance method of the  
> same name?
>
> I.e. say a class Foo implements both a +foo and a -foo method and you  
> have an instance called aFoo.
>
> You really want to be able to do...
>
>     Foo.foo(aFoo)
>
> ... and call the instance method.   But you also want to be able to  
> do...
>
>     Foo.foo()

That would be nice, but not possible. It might be possible to get  
'Foo.foo(Foo)' working if the class method has the same signature as  
the instance method, but that wouldn't allow overriding the class  
method in subclasses. But all is not lost, read on ;-)

>
> ... and call the class method.  Or, maybe, you want to do...
>
>     Foo.foo_(aFoo)
That would be [aFoo foo:] in Objective-C ;-). More seriously, that  
wouldn't be usefull because the Python runtime looks for 'Foo.foo' when  
you do 'aFoo.foo()'. This is what is causing us problems here.
>
> ... where you are calling the class method and passing an instance as  
> the argument?
>
> This isn't terribly clear, but I'm hoping it gets across the general  
> idea that we should be able to support both class and instance methods  
> that are named the same....
>
> One possibility would be to pass a kv argument that indicates that the  
> class implementation should be used if there is both a class and an  
> instance version-- i.e. Foo.foo(aFoo, useClassMethod=1)?
>
> But that would not allow an unbound version of the method to be  
> obtained that is explicitly tied to class or instance...?

We could mangle names of class methods, either by having a magic class  
property for accessing class methods or by adding a prefix/postfix to  
the methodname:

* Foo.__clsmeth__.foo()
* Foo._cls_foo()
* Foo.foo_cls()

I'd prefer the middle one given a suitable prefix: short, easily  
remembered and not likely to ever be used as the prefix of an  
Objective-C selector. If we go this route we should keep supporting the  
current behaviour; NSArray.arrayWithArray_ should not be renamed to  
NSArray._cls_arrayWithArray_, that would just be confusing. I'm not  
sure wether we should support both naming schemes for class methods  
that don't conflict with instance methods.

Ronald

[Pyobjc-dev] PyObjC Wiki...

[Jiva D. <ji...@de...>]

Ok, it only took a week... sorry for the delay, holidays and stuff...

Anyway, here's the URL: http://www.devoesquared.com/pyobjc-moin.cgi?

It's only got like 1 or 2 pages right now... let's go fill it up with 
stuff!

[Pyobjc-dev] unbound methods

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

On Monday, Dec 23, 2002, at 14:30 US/Eastern, Ronald Oussoren wrote:
>>     Rethinking this, the above method call may not work in some  
>> situations.  In particular, in class clusters it is often the case  
>> that you generally interact with some private subclass.  For example,  
>> NSArray.count(someArray) will not actually do what you want because  
>> instances of NSArray are never directly instantiated-- just private  
>> subclasses.
>>
>> In [6]: a = NSArray.arrayWithArray_([1,2,3,4,5])
>> In [7]: a.count()
>> Out[7]: 5
>> In [8]: NSArray.count(a)
>> ---------------------------------------------------------------------- 
>> -----
>> ValueError                                Traceback (most recent call  
>> last)
>>
>> ?
>>
>> ValueError: NSInvalidArgumentException - *** -count only defined for  
>> abstract class.  Define -[NSCFArray count]!
>>
>
> That's just like in 'normal' python types: If you call NSArray.count  
> you get the count method defined by NSArray instead of the one defined  
> by the class of your object. That is not very Objective-C-like, but  
> this is needed to implement super(cls, self).count().

Right.   However, the ability to use unbound methods is very much a  
feature of Python that a lot of people use...

Is there a way to support this a bit more cleanly/flexibly in light of  
ObjC's ability to have a class method and an instance method of the  
same name?

I.e. say a class Foo implements both a +foo and a -foo method and you  
have an instance called aFoo.

You really want to be able to do...

     Foo.foo(aFoo)

... and call the instance method.   But you also want to be able to  
do...

     Foo.foo()

... and call the class method.  Or, maybe, you want to do...

     Foo.foo_(aFoo)

... where you are calling the class method and passing an instance as  
the argument?

This isn't terribly clear, but I'm hoping it gets across the general  
idea that we should be able to support both class and instance methods  
that are named the same....

One possibility would be to pass a kv argument that indicates that the  
class implementation should be used if there is both a class and an  
instance version-- i.e. Foo.foo(aFoo, useClassMethod=1)?

But that would not allow an unbound version of the method to be  
obtained that is explicitly tied to class or instance...?

b.bum

Re: [Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

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

On Monday, Dec 30, 2002, at 16:05 US/Eastern, Ronald Oussoren wrote:
>> NSUndoManager is just a big proxy that keeps invocations in a stack--
> I noticed that, and I have to say that this a very neat way to 
> implement an undo mechanism.

Yes-- very, very cool-- it is the first place I point C++ programmers 
who complain about the fact that Apple should have just used C++ 
instead of inventing a "new" language (Obj-C is as old, if not older 
than C++)...

I ask them to implement the same kind of mechanism in C++ that is both 
as simple and elegant as the ObjC mechanism.

b.bum

Re: [Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

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

On Monday, Dec 30, 2002, at 21:52 Europe/Amsterdam, bb...@ma... wrote:

> On Monday, Dec 30, 2002, at 15:06 US/Eastern, Ronald Oussoren wrote:
>> I expected that this would work, but it clearly doesn't. This seems 
>> to be caused by a misunderstanding on my part of the semantics of 
>> 'NSObject.respondsToSelector:'. I expected that this returns true 
>> whenever 'NSObject.methodSignatureForSelector:' returns a non-nil 
>> value, but it doesn't.
>
> This is frequently not the case in the context of forwarded 
> invocations and other proxy-like behavior.  A class may return true to 
> respondsToSelector: but not actually provide a signature for the 
> selector.

I sure hope that will never happen because if 
methodSignatureForSelector returns nil PyObjC cannot construct the 
correct NSInvocation. Note that NSUndoManager does return non-nil from 
methodSignatureForSelector but sometimes returns FALSE from 
respondsToSelector for methods that it actually responds to. With the 
patch I just checked in this is no longer a problem.

>
> NSUndoManager is just a big proxy that keeps invocations in a stack--

I noticed that, and I have to say that this a very neat way to 
implement an undo mechanism.

Ronald

Re: [Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

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

On Monday, Dec 30, 2002, at 15:06 US/Eastern, Ronald Oussoren wrote:
> I expected that this would work, but it clearly doesn't. This seems to 
> be caused by a misunderstanding on my part of the semantics of 
> 'NSObject.respondsToSelector:'. I expected that this returns true 
> whenever 'NSObject.methodSignatureForSelector:' returns a non-nil 
> value, but it doesn't.

This is frequently not the case in the context of forwarded invocations 
and other proxy-like behavior.  A class may return true to 
respondsToSelector: but not actually provide a signature for the 
selector.

NSUndoManager is just a big proxy that keeps invocations in a stack-- 
it isn't surprising that the behavior of respondsToSelector: in the 
context of undo is a bit odd.

Re: [Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

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

On Monday, Dec 30, 2002, at 21:06 Europe/Amsterdam, I wrote:
>
>  Fixing this design-error won't be too hard.
Now that is an understatement. I've just checked in a fix :-)

>
> I'm not yet sure why 'm.methodSignatureForSelector_("foo:")' raises an 
> exception (it has nothing to do with the NSUndoManager class, 
> 'x.methodSignatureForSelector_("foo:")' raises the same exception.
It was the implementation of methodSignatureForSelector: for Python 
subclasses, also fixed.

Ronald

Re: [Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

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

On Monday, Dec 30, 2002, at 01:17 Europe/Amsterdam, David Eppstein 
wrote:

> Should
> NSUndoManager.prepareWithInvocationTarget_(x).some_Method_(arg,arg)
> work (where x is any object and some_Method_ is a selector handled by 
> x)?

I expected that this would work, but it clearly doesn't. This seems to 
be caused by a misunderstanding on my part of the semantics of 
'NSObject.respondsToSelector:'. I expected that this returns true 
whenever 'NSObject.methodSignatureForSelector:' returns a non-nil 
value, but it doesn't.

----- test.py --------

from Foundation import *

class Foo (NSObject):
     def test_(self, foo):
         print foo

x = Foo.new()

m = NSUndoManager.new()
m.prepareWithInvocationTarget_(x)
print x.respondsToSelector_('test:') # Prints 1
print m.respondsToSelector_('test:') # Prints 0?
print x.methodSignatureForSelector_('test:') # Prints 
<NSMethodSignature ...>
print m.methodSignatureForSelector_('test:') # Prints same value
print m.methodSignatureForSelector_('foo:')  # Raises AttributeError?
m.test_("hello world")
m.undo()

---- end of test.py ----

As I wrote earlier I expected 'm.respondsToSelector_('test:') to return 
1. Because it doesn't the bridge assumes that 'm' won't respond to 
'test_'. Fixing this design-error won't be too hard.

I'm not yet sure why 'm.methodSignatureForSelector_("foo:")' raises an 
exception (it has nothing to do with the NSUndoManager class, 
'x.methodSignatureForSelector_("foo:")' raises the same exception.

Ronald

Re: [Pyobjc-dev] Bridging of Strings

[David E. <epp...@ic...>]

On 12/30/02 7:43 AM +0100 Ronald Oussoren <ous...@ci...> wrote:
> It will be possible to use
> 'NSString.localizedCaseInsensitiveCompare_("foo", "bar")' in the next
> release. Until that time you could use the workaround described by Bill.
> Or if your brave you could use the CVS version that already contains this
> update ;-).

Thanks, will try the cvs version.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Bridging of Strings

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

On Monday, Dec 30, 2002, at 01:15 Europe/Amsterdam, David Eppstein 
wrote:

> On 12/23/02 8:30 PM +0100 Ronald Oussoren <ous...@ci...> wrote:
>>> ValueError: NSInvalidArgumentException - *** -count only defined for
>>> abstract class.  Define -[NSCFArray count]!
>>>
>>
>> That's just like in 'normal' python types: If you call NSArray.count  
>> you
>> get the count method defined by NSArray instead of the one defined  by
>> the class of your object. That is not very Objective-C-like, but  
>> this is
>> needed to implement super(cls, self).count().
>
> A possibly related recent surprise I had:
> I had an NSArray object X (or its Python proxy) and attempted to 
> retrieve X[-1].
> Got an NSRangeError rather than the expected last array item.
> Trivial to work around, but shouldn't this work?

Yup, it's a bug. I'll check in a fix later today.

>
>> That's not really a problem, just use the strint literal
>> "localizedCaseInsentiveCompare:" as the argument off
>> NSArray.sortedArrayUsingSelector_. By the time strings NSArray methods
>> touch the strings in an array they will be converted to NSString  
>> (that's
>> even true if the NSArray is the OC_PythonArray proxy for a  python
>> sequence).
>
> Well, except that what I really want to sort isn't an NSArray of 
> strings, it's a Python list of Python dictionaries, which I want to 
> sort according to the (localized case-independent) string values 
> stored under one of the keys in each dictionary.

It will be possible to use 
'NSString.localizedCaseInsensitiveCompare_("foo", "bar")' in the next 
release. Until that time you could use the workaround described by 
Bill. Or if your brave you could use the CVS version that already 
contains this update ;-).

Ronald

[Pyobjc-dev] NSUndoManager.prepareWithInvocationTarget_

[David E. <epp...@ic...>]

Should
NSUndoManager.prepareWithInvocationTarget_(x).some_Method_(arg,arg)
work (where x is any object and some_Method_ is a selector handled by x)?

When I tried it I got an error about no such attribute "some_Method_", I 
guess on the Python side, before it hit the ObjC forwardInvocation: 
handling of unknown methods.
-- 
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Bridging of Strings

[David E. <epp...@ic...>]

On 12/23/02 8:30 PM +0100 Ronald Oussoren <ous...@ci...> wrote:
>> ValueError: NSInvalidArgumentException - *** -count only defined for
>> abstract class.  Define -[NSCFArray count]!
>>
>
> That's just like in 'normal' python types: If you call NSArray.count  you
> get the count method defined by NSArray instead of the one defined  by
> the class of your object. That is not very Objective-C-like, but  this is
> needed to implement super(cls, self).count().

A possibly related recent surprise I had:
I had an NSArray object X (or its Python proxy) and attempted to retrieve 
X[-1].
Got an NSRangeError rather than the expected last array item.
Trivial to work around, but shouldn't this work?

> That's not really a problem, just use the strint literal
> "localizedCaseInsentiveCompare:" as the argument off
> NSArray.sortedArrayUsingSelector_. By the time strings NSArray methods
> touch the strings in an array they will be converted to NSString  (that's
> even true if the NSArray is the OC_PythonArray proxy for a  python
> sequence).

Well, except that what I really want to sort isn't an NSArray of strings, 
it's a Python list of Python dictionaries, which I want to sort according 
to the (localized case-independent) string values stored under one of the 
keys in each dictionary.
--
David Eppstein       UC Irvine Dept. of Information & Computer Science
epp...@ic... http://www.ics.uci.edu/~eppstein/

Re: [Pyobjc-dev] Bridging of Strings

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

On Monday, Dec 23, 2002, at 16:03 Europe/Amsterdam, bb...@ma... wrote:

> On Sunday, Dec 22, 2002, at 18:20 US/Eastern, David Eppstein wrote:
>> Shouldn't this work?
>>
>> NSString.localizedCaseInsensitiveCompare_('foo','bar')
>>
>> When I try it I get a complaint that the argument should be an  
>> NSString instead of a Python string.  I guess this means there is a  
>> signature missing somewhere?  I don't understand signatures well  
>> enough to correct it.
>>
>>
>> Really it would be better to be able to call
>> 'foo'.localizedCaseInsensitiveCompare_('bar')
>> but I can see why that's unlikely to work...
>
> That is exactly what you *should* be able to call but for another  
> problem.  Actually, either form should work in the Python sense.

NSString.localizedCaseInsensitiveCompare_(a, b) has some change of  
working in a future version, 'foo'.localizedCaseInsensitiveCompare_(b)  
will never work. That is, unless we change the python string type which  
IMHO is not advisable (and not possible: 'str.foo = 1' does not work).

>
> This is sort of a bug in the bridge and a feature.
>
> Bug:
>
> This....
>
>     NSString.localizedCaseInsensitiveCompare_('foo', 'bar')
>
>     ... should really work, but complains about "First argument must  
> be an objective-C object, got 'foo'".   I'm somewhat surprised that  
> the bridge doesn't convert 'foo' to an NSString as it hits the bridge  
> because it is a feature of the bridge to transparently convert Strings  
> to their native ObjC/Python type as they pass across the bridge.

Hmm... You have a point here. The current code knows that the first  
argument is 'self' and assumes this is already an Objective-C object.  
That is easily fixed, but as you noticed below that is probably not  
enough to get this to work. Clickety-click... It is pretty easy. I have  
this working for NSString in my tree, I'll check it in later but am not  
completely happy with the code yet. However:

 >>> NSString.localizedCaseInsensitiveCompare_('foo','bar')
1
 >>> NSString.localizedCaseInsensitiveCompare_('FOO', 'foo')
0

At least some methods work just fine...

>
>     Rethinking this, the above method call may not work in some  
> situations.  In particular, in class clusters it is often the case  
> that you generally interact with some private subclass.  For example,  
> NSArray.count(someArray) will not actually do what you want because  
> instances of NSArray are never directly instantiated-- just private  
> subclasses.
>
> In [6]: a = NSArray.arrayWithArray_([1,2,3,4,5])
> In [7]: a.count()
> Out[7]: 5
> In [8]: NSArray.count(a)
> ----------------------------------------------------------------------- 
> ----
> ValueError                                Traceback (most recent call  
> last)
>
> ?
>
> ValueError: NSInvalidArgumentException - *** -count only defined for  
> abstract class.  Define -[NSCFArray count]!
>

That's just like in 'normal' python types: If you call NSArray.count  
you get the count method defined by NSArray instead of the one defined  
by the class of your object. That is not very Objective-C-like, but  
this is needed to implement super(cls, self).count().

---
>
>     So-- given that we can't call the methods on NSString via the  
> class object, we really need to be able to pass an NSString across the  
> bridge such that it remains an NSString on the Python side.   There  
> are a number of reasons for this-- not duplicating data and having  
> access to the localization methods being the primary reasons.
>
>     A workaround (for David and others, not a recommendation for a  
> possible solution in the bridge):
>
>     Create an NSBundle that contains a category or class that wraps  
> the methods on NSString that you need access to.  I.e....
>
> @implementation NSString (BridgedMethods)
> + (NSComparisonResult)string: (NSString *) aString  
> localizedCaseInsensitiveCompare:(NSString *)bString;
> {
>     return [aString localizedCaseInsensitiveCompare: bString];
> }
> @end
>
> ... to be invoked [after loading] as ...
>
>     NSString.string_localizedCaseInsensitiveCompare_('foo', 'bar')
>
> ... not as elegant as an instance method and not directly compatible  
> with the various sorting methods on Array and the like
That's not really a problem, just use the strint literal  
"localizedCaseInsentiveCompare:" as the argument off  
NSArray.sortedArrayUsingSelector_. By the time strings NSArray methods  
touch the strings in an array they will be converted to NSString  
(that's even true if the NSArray is the OC_PythonArray proxy for a  
python sequence).

Ronald

[Pyobjc-dev] ANN: PyObjC 0.8

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

PyObjC version 0.8 is now available for download.

See...

     http://pyobjc.sourceforge.net/

... for more information.

The installer package includes a Project Builder project template for  
easily creating new Cocoa-Python projects and a slew of examples.   
Alternatively, the developer can choose to develop applications without  
using Apple's developer tools. Full support for Interface Builder  
documents is included.

The PyObjC Python module provides a feature complete bridge between the  
Python programming language and Objective-C. With PyObjC, it is  
possible to transparently message Objective-C objects from Python and  
Python objects from Objective-C. Objective-C objects can be subclassed  
from within Python.  Support is also included for using the various  
functions, enumerated types, and global variables found throughout the  
Objective-C framework.

References to python dictionaries pass into Objective-C act like a well  
behaved member of the NSDictionary class cluster. Likewise, Python List  
references behave like a member of the NSArray class cluster.
Strings are transparently converted to the native type.  NSArray and  
NSDictionary references passed into Python behave like native Python  
lists and dictionaries; including the ability to enumerate either using  
the 'in' operator and to slice NSArray and NSMutableArray instances.

PyObjC fully supports creating full featured Cocoa applications written  
in pure Python.  There are aspects of PyObjC that are more powerful  
than Cocoa in pure Obj-C (the ability to automatically define  
classes/outlets based on the contents of a NIB file, for example).

PyObjC requires OS X 10.2 or greater.  10.1 support is possible and  
will likely happen soon-- contact me if you need 10.1 support and are  
willing to do a bit of grunt work to generate the appropriate files  
(easy to do-- just need a 10.1 development machine).

The installer package is designed to work with the built-in Python  
provided in OS X 10.2.   Source is included on the disk image and the  
pyobjc module works with Python 2.2 or greater as installed directly  
from the Python Source, with the MacPython packages, and with the Fink  
build of python.

PyObjC also provides an awesome environment for exploring frameworks.    
The following transcript was copied out of a Terminal window-- it is an  
example of working directly with the Objective-C runtime from Python  
within the terminal.

 >>> from objc import *
 >>> from Foundation import *
 >>> b =  
NSBundle.bundleWithPath_("/System/Library/PrivateFrameworks/ 
PBXCore.framework")
 >>> b.principalClass()
<objective-c class PBXProducerTarget at 0xa9030034>
 >>> NSBundle.searchPathsForSupportFilesWithSubpath_("FooBar")
(
     "/Volumes/Data/Users/bbum/Developer/ProjectBuilder Extras/FooBar",
     "/Network/Developer/ProjectBuilder Extras/FooBar",
     "/Developer/ProjectBuilder Extras/FooBar"
)
 >>> PBXProject = lookUpClass("PBXProject")
 >>> p =  
PBXProject.projectWithFile_("/Developer/Examples/AppKit/TextEdit/ 
TextEdit.pbproj")
 >>> p.targets()
(<PBXApplicationTarget:0x00a76830:6FE2093EFE93D5F211CA2CEA:name='TextEdi 
t'>)
 >>> p.buildStyles()
(
      
<PBXBuildStyle:0x00a77d30:011ADBA3FF9FD52E11CA0C5D:name='Development':bu 
ildSettings.count=2>,
      
<PBXBuildStyle:0x00a82180:011ADBA4FF9FD52E11CA0C5D:name='Deployment':bui 
ldSettings.count=1>
)

The version # of 0.8 indicates that documentation is lacking, unit  
tests are incomplete and there may be a bug or two lurking within.  In  
practice, the module has proven to be very stable and to allow for the  
development of extremely complex Cocoa projects in pure Python or a mix  
of Python and Objective-C.

Re: [Pyobjc-dev] Stripping _objc.so

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

On Sunday, Dec 22, 2002, at 13:56 US/Eastern, Just van Rossum wrote:
>> For the installer package-- for the version that goes in
>> site-packages-- I don't think stripping makes a huge difference.
>
> (Btw. is "python setup.py install" equivalent to what the installer
> does?)

'setup.py install' only installs the module itself, not the project 
templates or examples.  The installer package installs all of that and 
will also try to prebind anything found within the package that can be 
prebound (it would be helpful if the various .so's could be prebound, 
but I don't know if that is even possible -- at the same time, it may 
already "just work" :-).

b.bum

[Pyobjc-dev] Bridging of Strings

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

On Sunday, Dec 22, 2002, at 18:20 US/Eastern, David Eppstein wrote:
> Shouldn't this work?
>
> NSString.localizedCaseInsensitiveCompare_('foo','bar')
>
> When I try it I get a complaint that the argument should be an  
> NSString instead of a Python string.  I guess this means there is a  
> signature missing somewhere?  I don't understand signatures well  
> enough to correct it.
>
>
> Really it would be better to be able to call
> 'foo'.localizedCaseInsensitiveCompare_('bar')
> but I can see why that's unlikely to work...

That is exactly what you *should* be able to call but for another  
problem.  Actually, either form should work in the Python sense.

This is sort of a bug in the bridge and a feature.

Bug:

This....

     NSString.localizedCaseInsensitiveCompare_('foo', 'bar')

     ... should really work, but complains about "First argument must be  
an objective-C object, got 'foo'".   I'm somewhat surprised that the  
bridge doesn't convert 'foo' to an NSString as it hits the bridge  
because it is a feature of the bridge to transparently convert Strings  
to their native ObjC/Python type as they pass across the bridge.

     Rethinking this, the above method call may not work in some  
situations.  In particular, in class clusters it is often the case that  
you generally interact with some private subclass.  For example,  
NSArray.count(someArray) will not actually do what you want because  
instances of NSArray are never directly instantiated-- just private  
subclasses.

In [6]: a = NSArray.arrayWithArray_([1,2,3,4,5])
In [7]: a.count()
Out[7]: 5
In [8]: NSArray.count(a)
------------------------------------------------------------------------ 
---
ValueError                                Traceback (most recent call  
last)

?

ValueError: NSInvalidArgumentException - *** -count only defined for  
abstract class.  Define -[NSCFArray count]!

---

     So-- given that we can't call the methods on NSString via the class  
object, we really need to be able to pass an NSString across the bridge  
such that it remains an NSString on the Python side.   There are a  
number of reasons for this-- not duplicating data and having access to  
the localization methods being the primary reasons.

     A workaround (for David and others, not a recommendation for a  
possible solution in the bridge):

     Create an NSBundle that contains a category or class that wraps the  
methods on NSString that you need access to.  I.e....

@implementation NSString (BridgedMethods)
+ (NSComparisonResult)string: (NSString *) aString  
localizedCaseInsensitiveCompare:(NSString *)bString;
{
     return [aString localizedCaseInsensitiveCompare: bString];
}
@end

... to be invoked [after loading] as ...

     NSString.string_localizedCaseInsensitiveCompare_('foo', 'bar')

... not as elegant as an instance method and not directly compatible  
with the various sorting methods on Array and the like.

     b.bum