pyobjc-dev — CVS commit notices go here

[Pyobjc-dev] [ pyobjc-Bugs-839536 ] libffi doesn't build when path has spaces in it

[SourceForge.net <no...@so...>]

Bugs item #839536, was opened at 2003-11-10 13:22
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=839536&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Josh Minor (joshminor)
Assigned to: Nobody/Anonymous (nobody)
Summary: libffi doesn't build when path has spaces in it

Initial Comment:
This took me a while to track down, so I thought I'd share it 
with others.  If you happen to be in a directory that has 
spaces in the name (as is often the case on the Mac) then 
libffi's configure script fails.

% pwd
/Volumes/Kyoto_HD/Users/joshm/foo bar/pyobjc-1.0
% /usr/bin/python setup.py
Performing task: Building FFI
/Volumes/Kyoto_HD/Users/joshm/foo bar/pyobjc-1.0/libffi-
src/configure: line 489: test: /Volumes/Kyoto_HD/Users/
joshm/foo: binary operator expected
/Volumes/Kyoto_HD/Users/joshm/foo bar/pyobjc-1.0/libffi-
src/configure: line 495: test: /Volumes/Kyoto_HD/Users/
joshm/foo: binary operator expected
configure: error: can not find install-sh or install.sh in  /
Volumes/Kyoto_HD/Users/joshm/foo bar/pyobjc-1.0/libffi-
src/
creating cache ./config.cache
checking for Cygwin environment... no
checking for mingw32 environment... no
Task 'Building FFI' failed [256]

This appears to be due to the fact that some $variables are 
not quoted properly, but the workaround it quite simple.  
Just build in a path with no spaces.

(also submitted as a bug in libffi)


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=839536&group_id=14534

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On 9 nov 2003, at 0:30, Jack Jansen wrote:

>
> On 7-nov-03, at 18:45, b.bum wrote:
>
>> On Nov 7, 2003, at 8:20 AM, Bob Ippolito wrote:
>>> No, it also happens when you are just using ObjC classes from the 
>>> Python side of the bridge.  It *always* binds to the instance 
>>> method, nomatter what, if it has one.  I'm not even worried about 
>>> overriding them from Python at the moment, just making ObjC classes 
>>> usable as they should be.
>>
>> Right -- and that is a bug.
>
> This hits the two-faced issue on the head: it's a bug if you look at 
> this with ObjC in mind, it's an essential shortcoming if you look at 
> it with Python in mind.
>
> Bob said (at some point in the past of this discussion) something to 
> the effect that someclass.somemehod is a selector. If you view it from 
> that angle then the current behavior is a bug.
> My initial thought (with my Python hat on) was that 
> someclass.somemethod is either a class method or an unbounded instance 
> method. Then this isn't a bug but a shortcoming that can't be 
> overcome.

That's a nice summary of the issues.

Having thought about this a little I wouldn't mind if we changed the 
selector code to be smarter about this, e.g.:

1) If the method is accessed through an instance it is always an 
instance method (and if there is only a class method we raise an 
AttributeError)
2) If the method is accessed through a class it is:
    - an unbound method if it is only an instance method
    - a bound method if it is only a class method
    - a "smart" method if it is both an instance method and a class 
method

Smart methods somehow detect how they are used (the number of arguments 
passed in springs to mind, if you call an unbound instance method you 
pass the self argument, if you call a bound class method you don't).

Other issues:
- if the class method has a different signature than the instance 
method we cannot create a "smart" method, I'd fall back to the current 
behaviour (e.g. return the instance method). It is highly unlikely that 
this ever happens.
- It *must* be possible to get information about instance methods 
through the class, otherwise we cannot create class browsers.
- If a "smart" method is overridden in a subclass, the subclass should 
still contain a "smart" method.

Ronald

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On 7-nov-03, at 18:45, b.bum wrote:

> On Nov 7, 2003, at 8:20 AM, Bob Ippolito wrote:
>> No, it also happens when you are just using ObjC classes from the 
>> Python side of the bridge.  It *always* binds to the instance method, 
>> nomatter what, if it has one.  I'm not even worried about overriding 
>> them from Python at the moment, just making ObjC classes usable as 
>> they should be.
>
> Right -- and that is a bug.

This hits the two-faced issue on the head: it's a bug if you look at 
this with ObjC in mind, it's an essential shortcoming if you look at it 
with Python in mind.

Bob said (at some point in the past of this discussion) something to 
the effect that someclass.somemehod is a selector. If you view it from 
that angle then the current behavior is a bug.
My initial thought (with my Python hat on) was that 
someclass.somemethod is either a class method or an unbounded instance 
method. Then this isn't a bug but a shortcoming that can't be overcome.
--
Jack Jansen, <Jac...@cw...>, 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] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 7, 2003, at 12:45 PM, b.bum wrote:

> On Nov 7, 2003, at 8:20 AM, Bob Ippolito wrote:
>> No, it also happens when you are just using ObjC classes from the 
>> Python side of the bridge.  It *always* binds to the instance method, 
>> nomatter what, if it has one.  I'm not even worried about overriding 
>> them from Python at the moment, just making ObjC classes usable as 
>> they should be.
>
> Right -- and that is a bug.
>
> "Binding" shouldn't occur until invocation except in the case where 
> the developer has explicitly invoked method via the unbound method 
> mechanism where they previously obtained a reference to the instance 
> or class version of a method.
>
> I.e. if I have...
>
> id foo;
>
> foo = ... something ...;
> [foo performSelector: @selector(description)];
>
> ... then the class or instance version of description will be invoked 
> depending on if foo is a class or instance object.

That's exactly what should happen, but that's not exactly how Python 
works..  Basically, selectors are descriptor instances.  When you get 
the selector-instance-turned-descriptor from the class or  instance it 
calls __get__(self, fromInstanceOrNone, fromClass) on the selector 
instance (tp_descr_get from the C API).  So, the selector instance 
needs to remember the values of fromInstanceOrNone and fromClass and 
return an object (perhaps itself, but maybe not) that's suitable to be 
introspected or called.  So, when you dispatch this object, you know if 
it was taken from the class or an instance (b/c fromInstanceOrNone 
would be None if it was taken from the class).

In the current PyObjC, at this point it has already decided if it's 
going to use a class or instance method.  Before dispatch happens.

If you read back a couple posts I had a mock-Python Selector class that 
shows how I would like the rules of the selector descriptor game to 
work, which should fix this bug.  The thing that I think you're 
confused about is that it's not clearly obvious what the target of the 
dispatch is..  obviously if the descriptor was taken from an instance, 
you know you want to use the instance version.  It gets more 
complicated if you want to make these things act more like Python 
objects, where you're allowed to do call instance methods off of the 
class directly.. see my next paragraph.

>>> I.e. if you do Foo.description to grab a reference to the 
>>> description method of the Foo class--  which has both +description 
>>> and -description-- then we should be able to figure out if the class 
>>> or instance implementation should be invoked at the time of dispatch 
>>> based on what the target of the invocation is.
>>>
>>> There are other details that would have to be worked out.  But, for 
>>> the most part, it would seem that this could be done in a largely 
>>> automatic and transparent fashion.   The remaining unknowns are 
>>> largely arbitrary in nature because they only occur due to the 
>>> combined interaction of the ObjC and Python runtimes -- we are free 
>>> to do whatever we want.
>>
>> That's what I was proposing, however there is some ambiguity in 
>> determining the target of the invocation if and only if we allow 
>> SomeClass.instanceMethod(someInstance) -- but I proposed a way that 
>> would figure that out most of the time, by counting the number of 
>> arguments given if that selector exists for both the class and the 
>> instance, which should work in every case that doesn't use varargs 
>> (do any?).
>
> If someInstance is an instance method, then the instance 
> implementation should be used... if it is a class method, then use the 
> class implementation.   This most closely mimics the ObjC runtime.

I should have said SomeClass.bothInstanceAndClassMethod(someInstance) 
-- doing this method-from-class-using-instance-as-argument thing 
creates a somewhat ambiguous case.  Without *counting* the number of 
arguments, you can't be sure whether you meant to call the instance 
version or the class version.  My suggested behavior breaks down when 
the number of arguments can not be reliably counted (varags).  I don't 
know if this actually happens or not with the bridge, and even if it 
did I would imagine that it would be extremely rare to find an ObjC 
class that implements the same varargs selector for class and instance.

> If the developer specifically wants the class vs. instance version of 
> the method, then we should add API for querying for the one versus the 
> other.   The API already exists on NSObject.

It's currently possible but ugly and unintuitive (I didn't even know 
about it, after looking at PyObjC's source code for hours).  My 
suggestion was to use: 
SomeClass.bothInstanceAndClassMethod.instanceMethod(...)
instead of:
SomeClass.pyobjc_instanceMethods.bothInstanceAndClassMethod(...)

(note that this would *never* be needed if my proposed semantics were 
implemented, *except* in the degenerate varargs case, if that case can 
even exist).

-bob

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 7, 2003, at 8:20 AM, Bob Ippolito wrote:
> No, it also happens when you are just using ObjC classes from the 
> Python side of the bridge.  It *always* binds to the instance method, 
> nomatter what, if it has one.  I'm not even worried about overriding 
> them from Python at the moment, just making ObjC classes usable as 
> they should be.

Right -- and that is a bug.

"Binding" shouldn't occur until invocation except in the case where the 
developer has explicitly invoked method via the unbound method 
mechanism where they previously obtained a reference to the instance or 
class version of a method.

I.e. if I have...

id foo;

foo = ... something ...;
[foo performSelector: @selector(description)];

... then the class or instance version of description will be invoked 
depending on if foo is a class or instance object.

>> I.e. if you do Foo.description to grab a reference to the description 
>> method of the Foo class--  which has both +description and 
>> -description-- then we should be able to figure out if the class or 
>> instance implementation should be invoked at the time of dispatch 
>> based on what the target of the invocation is.
>>
>> There are other details that would have to be worked out.  But, for 
>> the most part, it would seem that this could be done in a largely 
>> automatic and transparent fashion.   The remaining unknowns are 
>> largely arbitrary in nature because they only occur due to the 
>> combined interaction of the ObjC and Python runtimes -- we are free 
>> to do whatever we want.
>
> That's what I was proposing, however there is some ambiguity in 
> determining the target of the invocation if and only if we allow 
> SomeClass.instanceMethod(someInstance) -- but I proposed a way that 
> would figure that out most of the time, by counting the number of 
> arguments given if that selector exists for both the class and the 
> instance, which should work in every case that doesn't use varargs (do 
> any?).

If someInstance is an instance method, then the instance implementation 
should be used... if it is a class method, then use the class 
implementation.   This most closely mimics the ObjC runtime.

If the developer specifically wants the class vs. instance version of 
the method, then we should add API for querying for the one versus the 
other.   The API already exists on NSObject.

b.bum

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 7, 2003, at 10:53 AM, b.bum wrote:

> Unless I'm missing something, can't we always tell at the moment of 
> dispatch whether or not a particular method should be resolved in the 
> class or instance context?
>
> When objc_msgSend() is invoked, the SEL parameter is resolved 
> internally based on the 'self' parameter -- on the target of 
> invocation.   So, once we have an object reference and a selector, our 
> bridged dispatch to the method IMP should "just work" regardless of 
> whether it is a class or instance.
>
> The only place that class vs. instance method is problematic would 
> appear to be within the Python subclasses of ObjC objects where there 
> is a need to define both a class and an instance method.  I.e. 
> +description vs. -description.

No, it also happens when you are just using ObjC classes from the 
Python side of the bridge.  It *always* binds to the instance method, 
nomatter what, if it has one.  I'm not even worried about overriding 
them from Python at the moment, just making ObjC classes usable as they 
should be.

> Given that +description requires, effectively, a redeclaration through 
> the use of selector(), we could change the name of the method 
> slightly-- and invisibly-- at that time.
>
> But that is ugly.
>
> Instead, can we handle this at the time of dispatch?

Sure, that's what I'm asking for :)

> I.e. if you do Foo.description to grab a reference to the description 
> method of the Foo class--  which has both +description and 
> -description-- then we should be able to figure out if the class or 
> instance implementation should be invoked at the time of dispatch 
> based on what the target of the invocation is.
>
> There are other details that would have to be worked out.  But, for 
> the most part, it would seem that this could be done in a largely 
> automatic and transparent fashion.   The remaining unknowns are 
> largely arbitrary in nature because they only occur due to the 
> combined interaction of the ObjC and Python runtimes -- we are free to 
> do whatever we want.

That's what I was proposing, however there is some ambiguity in 
determining the target of the invocation if and only if we allow 
SomeClass.instanceMethod(someInstance) -- but I proposed a way that 
would figure that out most of the time, by counting the number of 
arguments given if that selector exists for both the class and the 
instance, which should work in every case that doesn't use varargs (do 
any?).

-bob

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

Unless I'm missing something, can't we always tell at the moment of 
dispatch whether or not a particular method should be resolved in the 
class or instance context?

When objc_msgSend() is invoked, the SEL parameter is resolved 
internally based on the 'self' parameter -- on the target of 
invocation.   So, once we have an object reference and a selector, our 
bridged dispatch to the method IMP should "just work" regardless of 
whether it is a class or instance.

The only place that class vs. instance method is problematic would 
appear to be within the Python subclasses of ObjC objects where there 
is a need to define both a class and an instance method.  I.e. 
+description vs. -description.

Given that +description requires, effectively, a redeclaration through 
the use of selector(), we could change the name of the method 
slightly-- and invisibly-- at that time.

But that is ugly.

Instead, can we handle this at the time of dispatch?

I.e. if you do Foo.description to grab a reference to the description 
method of the Foo class--  which has both +description and 
-description-- then we should be able to figure out if the class or 
instance implementation should be invoked at the time of dispatch based 
on what the target of the invocation is.

There are other details that would have to be worked out.  But, for the 
most part, it would seem that this could be done in a largely automatic 
and transparent fashion.   The remaining unknowns are largely arbitrary 
in nature because they only occur due to the combined interaction of 
the ObjC and Python runtimes -- we are free to do whatever we want.

b.bum

Re: [Pyobjc-dev] ScreenSaver Example

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

On Nov 7, 2003, at 7:04 AM, Ronald Oussoren wrote:
> :-(. Luckily I did spell it correctly in the plist. BTW. Only adding 
> NSPrincipalClass didn't work, NSMainNibFile was required.

In a bundle?  That seems odd.  Please file a radar!

b.bum

Re: [Pyobjc-dev] ScreenSaver Example

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

On 7 nov 2003, at 15:55, Bob Ippolito wrote:

>
> On Nov 7, 2003, at 9:26 AM, Ronald Oussoren wrote:
>
>>
>> On 5 nov 2003, at 1:13, Jason Toffaletti wrote:
>>
>>> Well I tried that with the screensaver, and I get this error with 
>>> pyobjc from CVS.
>>>
>>> loading python screen saver
>>> 2003-11-04 15:51:52.369 System Preferences[9755] *** 
>>> -[_PyObjC_BundleHelper_SillyBalls_ initWithFrame:isPreview:]: 
>>> selector not recognized
>>
>> I should have noticed this earlier, _PyObjC_BundleHeader_SillyBalls_ 
>> is an Objective-C class introduced by pluginbuilder. This class loads 
>> the Python interpreter and then loads your python code. For some 
>> reason this is picked up as the principle class.
>>
>> If I change the Info.plist of your NIB-less saver and include an 
>> NSPrincipleClass (SillyBalls) and NSMainNib (SillyBalls) key the 
>> saver works correctly, even though the NIB-file does not exist!
>
> Also, please make sure to spell it correctly, otherwise it won't work. 
>  it's NSPrincip*al*Class, sans asterisks.

:-(. Luckily I did spell it correctly in the plist. BTW. Only adding 
NSPrincipalClass didn't work, NSMainNibFile was required.

Ronald

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 7, 2003, at 6:34 AM, Jack Jansen wrote:

>
> On 5 Nov 2003, at 23:44, Bob Ippolito wrote:
>>>> NSObject.foo()  				# smart decision by the selector (smarter than 
>>>> instance if it has one, see previous email)
>>>> NSObject.foo.classMethod() 		# classmethod
>>>> NSObject.foo.instanceMethod() 	# instanceMethod
>>>
>>> That would make "NSObject.foo" a funny sort of object. In the 
>>> current scheme NSObject.foo is a perfectly normal object, either an 
>>> unbound method or a class method.
>>
>> Except that it has a signature, isClassMethod, etc.  It's not a 
>> perfectly normal object, it's a selector instance.  One of the big 
>> "selling points" of ObjC is that you can pretty much translate ObjC 
>> code to Python, this is a stumbling block I think we should work 
>> around.
>
> Hmm, you have a point. If I look at this then sometimes I agree with 
> you, sometimes I agree with myself. It really depends on whether you 
> take a Pythonic view or on ObjC-view.

Well the way I see it is this.  Making selectors more magical will make 
ObjC code work more often without "change".  The only thing that 
*might* break is doing SomeClass.someInstanceSelector(someInstance, 
...) -- but people only really do that if someInstance is a string or 
something weird is going on with PyObjC.. I really don't think this 
change would cause any problems, and I don't think that the 
classMethod/instanceMethod members would ever really need to be used, 
but would be there as a backup plan in case for some reason PyObjC 
guessed wrong and you really want to use a instance method that was 
taken off the class.  classMethod is only there for symmetry, it would 
never be necessary.

-bob

Re: [Pyobjc-dev] ScreenSaver Example

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

On Nov 7, 2003, at 9:26 AM, Ronald Oussoren wrote:

>
> On 5 nov 2003, at 1:13, Jason Toffaletti wrote:
>
>> Well I tried that with the screensaver, and I get this error with 
>> pyobjc from CVS.
>>
>> loading python screen saver
>> 2003-11-04 15:51:52.369 System Preferences[9755] *** 
>> -[_PyObjC_BundleHelper_SillyBalls_ initWithFrame:isPreview:]: 
>> selector not recognized
>
> I should have noticed this earlier, _PyObjC_BundleHeader_SillyBalls_ 
> is an Objective-C class introduced by pluginbuilder. This class loads 
> the Python interpreter and then loads your python code. For some 
> reason this is picked up as the principle class.
>
> If I change the Info.plist of your NIB-less saver and include an 
> NSPrincipleClass (SillyBalls) and NSMainNib (SillyBalls) key the saver 
> works correctly, even though the NIB-file does not exist!

Also, please make sure to spell it correctly, otherwise it won't work.  
it's NSPrincip*al*Class, sans asterisks.

-bob

Re: [Pyobjc-dev] ScreenSaver Example

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

On 5 nov 2003, at 1:13, Jason Toffaletti wrote:

> Well I tried that with the screensaver, and I get this error with 
> pyobjc from CVS.
>
> loading python screen saver
> 2003-11-04 15:51:52.369 System Preferences[9755] *** 
> -[_PyObjC_BundleHelper_SillyBalls_ initWithFrame:isPreview:]: selector 
> not recognized

I should have noticed this earlier, _PyObjC_BundleHeader_SillyBalls_ is 
an Objective-C class introduced by pluginbuilder. This class loads the 
Python interpreter and then loads your python code. For some reason 
this is picked up as the principle class.

If I change the Info.plist of your NIB-less saver and include an 
NSPrincipleClass (SillyBalls) and NSMainNib (SillyBalls) key the saver 
works correctly, even though the NIB-file does not exist!

Ronald

Re: [Pyobjc-dev] Real case for using PyObjC bundles

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

On 7 nov 2003, at 12:52, Dinu Gherman wrote:

> Has anybody made some experience using such bundles with PyObjC? The
> issues, as I mentioned previously, are basically to load the NIB and
> instantiate some instance of a controller/owner class to handle it.
> The bundles could be considered documents in a document-based app,
> but with additional specific NIB files for their configuration.
>
> I expect the usual ObjC approach using NSBundle's principleClass me-
> thod not to be working in PyObjC directly and wonder what the best
> approach would be for doing this? I've sort of tried using the PyObjC
> tool PyObjCTools.NibClassBuilder.extractClasses() but maybe not sys-
> tematically enough yet to succeed.

PyObjCTools.pluginbuilder should be useable here, but would be overkill 
if both the main program and the plugins are Python-based. You could 
use the approach used by those plugin modules:

- Load the bundle using NSBundle
- Look for the main python file (either hardcode a name, or use a key 
in the Info.plist)
- Create a new module object, set __path__ to the resources directory 
of the bundle, and
   execute the main python file in that module
- Now look for the main class using NSBundle.principleClass

Setting the __path__ is important, this way the resources directory is 
treated like a package which makes it possible to use the same module 
names in two plugins.

Ronald

Re: [Pyobjc-dev] Real case for using PyObjC bundles

[Zachery B. <zb...@ur...>]

On Nov 7, 2003, at 6:52 AM, Dinu Gherman wrote:

> Hi,
>
> I'm working on a PyObjC app that should make use of plugins, which
> need to be configurable, so they need to have NIB files, too. It's
> pretty dynamic, but you can see a static screenshot of it here:
> http://python.net/~gherman/UnreleasedStuff.html (the one with the
> blue background). There's also a poor quality Quicktime movie:
> http://python.net/~gherman/tmp/Konglomerator002.mov

Konfabulator Killer? :)

Zac

[Pyobjc-dev] Real case for using PyObjC bundles

[Dinu G. <gh...@da...>]

Hi,

I'm working on a PyObjC app that should make use of plugins, which
need to be configurable, so they need to have NIB files, too. It's
pretty dynamic, but you can see a static screenshot of it here:
http://python.net/~gherman/UnreleasedStuff.html (the one with the
blue background). There's also a poor quality Quicktime movie:
http://python.net/~gherman/tmp/Konglomerator002.mov

Has anybody made some experience using such bundles with PyObjC? The
issues, as I mentioned previously, are basically to load the NIB and
instantiate some instance of a controller/owner class to handle it.
The bundles could be considered documents in a document-based app,
but with additional specific NIB files for their configuration.

I expect the usual ObjC approach using NSBundle's principleClass me-
thod not to be working in PyObjC directly and wonder what the best
approach would be for doing this? I've sort of tried using the PyObjC
tool PyObjCTools.NibClassBuilder.extractClasses() but maybe not sys-
tematically enough yet to succeed.

Any help to solve this is much appreciated, because you can do very
very nice stuff which is just not configurable, yet. There is also a
potential for running the same code in "screensaver mode", but that
is secondary to me...

Dinu

--
Dinu C. Gherman - http://python.net/~gherman
......................................................................
"I'll let you be in my dream if I can be in yours." (Bob Dylan)

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On 5 Nov 2003, at 23:44, Bob Ippolito wrote:
>>> NSObject.foo()  				# smart decision by the selector (smarter than 
>>> instance if it has one, see previous email)
>>> NSObject.foo.classMethod() 		# classmethod
>>> NSObject.foo.instanceMethod() 	# instanceMethod
>>
>> That would make "NSObject.foo" a funny sort of object. In the current 
>> scheme NSObject.foo is a perfectly normal object, either an unbound 
>> method or a class method.
>
> Except that it has a signature, isClassMethod, etc.  It's not a 
> perfectly normal object, it's a selector instance.  One of the big 
> "selling points" of ObjC is that you can pretty much translate ObjC 
> code to Python, this is a stumbling block I think we should work 
> around.

Hmm, you have a point. If I look at this then sometimes I agree with 
you, sometimes I agree with myself. It really depends on whether you 
take a Pythonic view or on ObjC-view.
--
Jack Jansen        <Jac...@cw...>        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] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 5, 2003, at 5:24 PM, Jack Jansen wrote:

> On 5-nov-03, at 17:26, Bob Ippolito wrote:
>
>>
>> On Nov 5, 2003, at 5:00 AM, Ronald Oussoren wrote:
>>
>>> 	NSObject.foo()		# Instancemethod, or if that does not exist 
>>> classmethod
>>> 	NSObject.pyobjc_classMethods.foo()	# Classmethod
>>> 	NSObject.pyobjc_instanceMethods.foo()	# Instancemethod
>>
>> Another idea - how about putting that on the selector instead?
>>
>> NSObject.foo()  				# smart decision by the selector (smarter than 
>> instance if it has one, see previous email)
>> NSObject.foo.classMethod() 		# classmethod
>> NSObject.foo.instanceMethod() 	# instanceMethod
>
> That would make "NSObject.foo" a funny sort of object. In the current 
> scheme NSObject.foo is a perfectly normal object, either an unbound 
> method or a class method.

Except that it has a signature, isClassMethod, etc.  It's not a 
perfectly normal object, it's a selector instance.  One of the big 
"selling points" of ObjC is that you can pretty much translate ObjC 
code to Python, this is a stumbling block I think we should work 
around.  With the "algorithm" I posted earlier, using these special 
"classMethod / instanceMethod" accessors should never really be 
necessary, except in rare instances where you are doing 
SomeClass.someInstanceMethod(instance, ...) with varargs or something.

-bob

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On 5-nov-03, at 17:26, Bob Ippolito wrote:

>
> On Nov 5, 2003, at 5:00 AM, Ronald Oussoren wrote:
>
>> 	NSObject.foo()		# Instancemethod, or if that does not exist 
>> classmethod
>> 	NSObject.pyobjc_classMethods.foo()	# Classmethod
>> 	NSObject.pyobjc_instanceMethods.foo()	# Instancemethod
>
> Another idea - how about putting that on the selector instead?
>
> NSObject.foo()  				# smart decision by the selector (smarter than 
> instance if it has one, see previous email)
> NSObject.foo.classMethod() 		# classmethod
> NSObject.foo.instanceMethod() 	# instanceMethod

That would make "NSObject.foo" a funny sort of object. In the current 
scheme NSObject.foo is a perfectly normal object, either an unbound 
method or a class method.
--
Jack Jansen, <Jac...@cw...>, 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] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 5, 2003, at 5:00 AM, Ronald Oussoren wrote:

> 	NSObject.foo()		# Instancemethod, or if that does not exist 
> classmethod
> 	NSObject.pyobjc_classMethods.foo()	# Classmethod
> 	NSObject.pyobjc_instanceMethods.foo()	# Instancemethod

Another idea - how about putting that on the selector instead?

NSObject.foo()  				# smart decision by the selector (smarter than 
instance if it has one, see previous email)
NSObject.foo.classMethod() 		# classmethod
NSObject.foo.instanceMethod() 	# instanceMethod

-bob

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 5, 2003, at 5:00 AM, Ronald Oussoren wrote:

> Ideally one would be able to do NSObject.description().. which means 
> that the descriptor has to know about these "class or instance" 
> methods.  It's also, as far as I know, not possible to override the 
> class implementation for a selector if an instance implementation 
> exists (from Python).
>
> Note that it is currently not possible to know of 
> 'NSObject.description' refers to the class or instance method due to 
> the way types are implemented in Python:
>
> 	obj.description()
>
> is basically implemented as:
> 	
> 	obj.__class__.description(obj)
>
> And furthermore Cocoa classes should 'feel' as much as Python classes 
> as possible, it should therefore be possible to call 
> 'NSObject.description(obj)'.

Well the current semantics for instance method only and class method 
only are perfectly fine.. it's the occasions when a particular selector 
is implemented both ways where things start to get hairy.  I'd rather 
have NSObject.description(obj) not work, if it meant that 
NSObject.description() did work.  Even still, I think enough 
information is available to make it possible.  What about something 
like this (sorta pseudocode, not in tp_descr_get C API).

METH_CLASS = 1 << 0
METH_INST  = 1 << 1

class Selector(object):
     EXPECTED_ARG_LEN = 0
     def __init__(self, name, flags, boundklass=None, boundinst=None):
         self.name = name
         self.flags = flags
         self.boundklass = boundklass
         self.boundinst = boundinst

     def __get__(self, inst, klass):
         if inst is None:
             return Selector(self.name, self.flags, boundklass=klass)
         elif not (self.flags & METH_INST):
             # trying to get a pure class method from an instance, don't 
do that
             raise AttributeError, "%s is a class method" % (self.name,)
         # it's been acquired from an instance
         return Selector(self.name, self.flags, boundinst=inst, 
boundklass=klass)

     def __call__(self, *args):
         if self.boundklass is None and self.boundinst is None:
             raise ValueError, "Selector not initialized"
         elif self.boundinst is not None:
             # acquired from an instance..
             return execute(self.boundinst, args)
         elif self.flags & METH_INST and len(args) > 
self.EXPECTED_ARG_LEN:
             # must be using class.instanceMethod(instance, ....)
             # so what if this breaks down on varargs? how are varargs 
wrapped anyway (if at all)?
             # those people can use a workaround or just not use 
klass.instanceMethod(instance, ...)
             return execute(args[0], args[1:])
         else:
             return execute(self.boundklass, args)

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

Managment summary:

use 'NSWindow.pyobjc_classMethods.contentRectForFrameRect_styleMask_'  
to call the class method.

On 5 nov 2003, at 9:23, Bob Ippolito wrote:

> On Nov 4, 2003, at 10:56 PM, SourceForge.net wrote:
>
>> Bugs item #836247, was opened at 2003-11-05 03:56
>> Message generated for change (Tracker Item Submitted) made by Item  
>> Submitter
>> You can respond by visiting:
>> https://sourceforge.net/tracker/? 
>> func=detail&atid=114534&aid=836247&group_id=14534
>
> This bug exposes a fairly obnoxious problem in the current  
> implementation of PyObjC: there are not separate namespaces for class  
> and instance methods, so you end up with stupid problems when you have  
> some class that implements the same selector for both the instance and  
> class.  There's a lot of pretty common selectors that are like this:
> 	+[NSObject description]
> 	-[NSObject description]
> 	.. etc ..

I noticed. It is already possible to call both methods, although not  
necessarily in a very convenient way:

	NSObject.foo()		# Instancemethod, or if that does not exist classmethod
	NSObject.pyobjc_classMethods.foo()	# Classmethod
	NSObject.pyobjc_instanceMethods.foo()	# Instancemethod

At the time we ran into this issue I couldn't find any methods where it  
would be usefull to override the class method, it is therefore not  
possible to override the class method at the moment.

>
> I did discover a workaround, which is  
> ClassObject.bothClassAndInstanceMethod(ClassObject).. for example:
> >>> NSObject.description(NSObject)
> u'<NSObject: 0xa0a04e40>'

That's more a bug than a feature...

>
> Ideally one would be able to do NSObject.description().. which means  
> that the descriptor has to know about these "class or instance"  
> methods.  It's also, as far as I know, not possible to override the  
> class implementation for a selector if an instance implementation  
> exists (from Python).

Note that it is currently not possible to know of  
'NSObject.description' refers to the class or instance method due to  
the way types are implemented in Python:

	obj.description()

is basically implemented as:
	
	obj.__class__.description(obj)

And furthermore Cocoa classes should 'feel' as much as Python classes  
as possible, it should therefore be possible to call  
'NSObject.description(obj)'.

>
> So my question is, how the heck do we approach this?  It seems that  
> the current selector objects/descriptors need to be changed quite a  
> bit in order to facilitate this, especially allowing one to do it from  
> Python.  Perhaps we can change the selector function to take a class  
> function, instance function, or both.. and throw away isClassMethod.   
> We can add a flag on the selector that says "I have both a class and  
> an instance".  I'm pretty new to these internals.. so, Ronald, do you  
> want to handle this one?  Or give me some ideas as to how this should  
> be done?

Is it necessary to be able to override class methods? My gut feeling is  
that it would be easy-ish to change objc.selector() to allow something  
like this:

	class FooClass (NSObject):
		def _cls_description(cls):
			return "FooClass class"

		def _inst_description(self):
			return "FooClass instance"

		description = objc.selector(selector="description",  
clsImp=_cls_description, instImp=_inst_description)

		del _cls_description, _inst_description

This is pretty ugly, but at least would make it possible to override  
both the class and instance method without introducing an additional  
class.

However, I don't think this is worth the effort unless someone has a  
real use case. 	

Ronald

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 5, 2003, at 3:23 AM, Bob Ippolito wrote:

> On Nov 4, 2003, at 10:56 PM, SourceForge.net wrote:
>
>> Bugs item #836247, was opened at 2003-11-05 03:56
>> Message generated for change (Tracker Item Submitted) made by Item  
>> Submitter
>> You can respond by visiting:
>> https://sourceforge.net/tracker/? 
>> func=detail&atid=114534&aid=836247&group_id=14534
>
> This bug exposes a fairly obnoxious problem in the current  
> implementation of PyObjC: there are not separate namespaces for class  
> and instance methods, so you end up with stupid problems when you have  
> some class that implements the same selector for both the instance and  
> class.  There's a lot of pretty common selectors that are like this:
> 	+[NSObject description]
> 	-[NSObject description]
> 	.. etc ..
>
> I did discover a workaround, which is  
> ClassObject.bothClassAndInstanceMethod(ClassObject).. for example:
> >>> NSObject.description(NSObject)
> u'<NSObject: 0xa0a04e40>'
>
> Ideally one would be able to do NSObject.description().. which means  
> that the descriptor has to know about these "class or instance"  
> methods.  It's also, as far as I know, not possible to override the  
> class implementation for a selector if an instance implementation  
> exists (from Python).
>
> So my question is, how the heck do we approach this?  It seems that  
> the current selector objects/descriptors need to be changed quite a  
> bit in order to facilitate this, especially allowing one to do it from  
> Python.  Perhaps we can change the selector function to take a class  
> function, instance function, or both.. and throw away isClassMethod.   
> We can add a flag on the selector that says "I have both a class and  
> an instance".  I'm pretty new to these internals.. so, Ronald, do you  
> want to handle this one?  Or give me some ideas as to how this should  
> be done?

Ok, I was totally wrong about that workaround..  Anyhow:
 >>> NSObject.pyobjc_classMethods.description()
u'NSObject'
 >>> NSObject.alloc().init().pyobjc_instanceMethods.description()
u'<NSObject: 0x3a3c60>'

That is the real workaround..  fixed tests checked in.

-bob

[Pyobjc-dev] [ pyobjc-Bugs-836342 ] Should ObjC class methods be callable from PyObjC instances?

[SourceForge.net <no...@so...>]

Bugs item #836342, was opened at 2003-11-05 03:46
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=836342&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Should ObjC class methods be callable from PyObjC instances?

Initial Comment:
Should we really allow stuff like 
NSBundle.mainBundle().mainBundle()?  This currently works, 
I don't think it should.  I think that class methods should act 
more like they were implemented on a metaclass.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=836342&group_id=14534

[Pyobjc-dev] [ pyobjc-Bugs-836336 ] Lots of typing involved for selectors that map to keywords

[SourceForge.net <no...@so...>]

Bugs item #836336, was opened at 2003-11-05 03:39
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=836336&group_id=14534

Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Submitted By: Bob Ippolito (etrepum)
Assigned to: Nobody/Anonymous (nobody)
Summary: Lots of typing involved for selectors that map to keywords

Initial Comment:
For example:
>>> from Foundation import NSObject
>>> import keyword
>>> [kw for kw in keyword.kwlist if kw in 
NSObject.__dict__]
['class']

I'm not currently aware of any commonly used ObjC classes 
that use keywords for selectors.. however, that doesn't mean 
that there won't be any.  Yes, I know this example is stupid 
because there is __class__, but there isn't special treatment 
for selectors called "pass" "assert", etc.

Workarounds:
NSObject.__dict__['class']
getattr(NSObject, 'class')

Proposed solution:
NSObject.class__ ?  Appending two underscores seems like 
the logical thing to do.. prepending them makes you think 
special method or private implementation, but appending 
two could do the trick.  Since there aren't any keywords with 
underscores in them, it's pretty clear that the selector for 
this is "class".

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=114534&aid=836336&group_id=14534

Re: [Pyobjc-dev] [ pyobjc-Bugs-836247 ] NSWindow.contentRectForFrameRect_styleMask_ not a class meth

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

On Nov 4, 2003, at 10:56 PM, SourceForge.net wrote:

> Bugs item #836247, was opened at 2003-11-05 03:56
> Message generated for change (Tracker Item Submitted) made by Item  
> Submitter
> You can respond by visiting:
> https://sourceforge.net/tracker/? 
> func=detail&atid=114534&aid=836247&group_id=14534

This bug exposes a fairly obnoxious problem in the current  
implementation of PyObjC: there are not separate namespaces for class  
and instance methods, so you end up with stupid problems when you have  
some class that implements the same selector for both the instance and  
class.  There's a lot of pretty common selectors that are like this:
	+[NSObject description]
	-[NSObject description]
	.. etc ..

I did discover a workaround, which is  
ClassObject.bothClassAndInstanceMethod(ClassObject).. for example:
 >>> NSObject.description(NSObject)
u'<NSObject: 0xa0a04e40>'

Ideally one would be able to do NSObject.description().. which means  
that the descriptor has to know about these "class or instance"  
methods.  It's also, as far as I know, not possible to override the  
class implementation for a selector if an instance implementation  
exists (from Python).

So my question is, how the heck do we approach this?  It seems that the  
current selector objects/descriptors need to be changed quite a bit in  
order to facilitate this, especially allowing one to do it from Python.  
  Perhaps we can change the selector function to take a class function,  
instance function, or both.. and throw away isClassMethod.  We can add  
a flag on the selector that says "I have both a class and an instance".  
  I'm pretty new to these internals.. so, Ronald, do you want to handle  
this one?  Or give me some ideas as to how this should be done?

-bob