> On 24 Jul 2016, at 13:06, Ronald Oussoren <[email protected]
> <mailto:[email protected]>> 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 | [email protected] <mailto:[email protected]> |
>> Brisbane, Australia
>
> _______________________________________________
> Python-Dev mailing list
> [email protected] <mailto:[email protected]>
> 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
[email protected]
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
