> On 24 Jul 2016, at 13:06, Ronald Oussoren <ronaldousso...@mac.com 
> <mailto:ronaldousso...@mac.com>> wrote:
> 
…

> But on the other hand, that’s why wanted to use PyObjC to validate
> the PEP in the first place.

I’ve hit a fairly significant issue with this, PyObjC’s super contains more 
magic than just this magic that would be fixed by PEP 447. I don’t think I’ll 
be able to finish work on PEP 447 this week because of that, and in the worst 
case will have to retire the PEP.

The problem is as follows: to be able to map all of Cocoa’s methods to Python 
PyObjC creates two proxy classes for every Cocoa class: the regular class and 
its metaclass. The latter is used to store class methods. This is needed 
because Objective-C classes can have instance and class methods with the same 
name, as an example:

@interface NSObject
-(NSString*)description;
+(NSString*)description
@end

The first declaration for “description” is an instance method, the second is a 
class method.  The Python metaclass is mostly a hidden detail, users don’t 
explicitly interact with these classes and use the normal Python convention for 
defining class methods.

This works fine, problems starts when you want to subclass in Python and 
override the class method:

class MyClass (NSObject):
   @classmethod
   def description(cls): 
      return “hello there from %r” % (super(MyClass, cls).description())

If you’re used to normal Python code there’s nothing wrong here, but getting 
this to work required some magic in objc.super to ensure that its 
__getattribute__ looks in the metaclass in this case and not the regular class. 
 The current PEP447-ised version of PyObjC has a number of test failures 
because builtin.super obviously doesn’t contain this hack (and shouldn’t). 

I think I can fix this for modern code that uses an argumentless call to super 
by replacing the cell containing the __class__ reference when moving the method 
from the regular class to the instance class. That would obviously not work for 
the code I showed earlier, but that at least won’t fail silently and the error 
message is specific enough that I can include it in PyObjC’s documentation.

Ronald




> 
> Back to wrangling C code,
> 
>   Ronald
> 
> 
>> 
>> Cheers,
>> Nick.
>> 
>> -- 
>> Nick Coghlan   |   ncogh...@gmail.com <mailto:ncogh...@gmail.com>   |   
>> Brisbane, Australia
> 
> _______________________________________________
> Python-Dev mailing list
> Python-Dev@python.org <mailto:Python-Dev@python.org>
> https://mail.python.org/mailman/listinfo/python-dev 
> <https://mail.python.org/mailman/listinfo/python-dev>
> Unsubscribe: 
> https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com 
> <https://mail.python.org/mailman/options/python-dev/ronaldoussoren%40mac.com>
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Reply via email to