On 24 Jul 2016, at 13:06, Ronald Oussoren <ronaldoussoren@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.

The next steps for me are to fix the remaining issues in PyObjC’s support for PEP 447, and trying to implement the replacement of __class__. If that works out I’ll finish the PEP and ask for a pronouncement. If that doesn’t work out I’ll at least report on that.

Ronald





Back to wrangling C code,

  Ronald



Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan@gmail.com   |   Brisbane, Australia

_______________________________________________
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/ronaldoussoren%40mac.com