Hi Ronald, The feature freeze for 3.6 is closing in a few days; 3.6b1 will go out this weekend. Did you overcome the issue, or does your PEP need to be postponed until 3.7?
--Guido On Sun, Jul 24, 2016 at 9:58 PM, Ronald Oussoren <ronaldousso...@mac.com> wrote: > > On 24 Jul 2016, at 13:06, Ronald Oussoren <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 | 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 > > > > _______________________________________________ > 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/guido%40python.org > -- --Guido van Rossum (python.org/~guido) _______________________________________________ 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
