Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-09-06 Thread Guido van Rossum
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 wrote: > > On 24 Jul 2016, at 13:06, Ronald Oussoren wrote: > >

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-07-24 Thread Ronald Oussoren
> On 24 Jul 2016, at 13:06, Ronald Oussoren > 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 tha

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-07-24 Thread Ronald Oussoren
On 24 Jul 2016, at 13:06, Ronald Oussoren wrote:…But on the other hand, that’s why wanted to use PyObjC to validatethe 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 44

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-07-24 Thread Ronald Oussoren
> On 24 Jul 2016, at 12:37, Nick Coghlan wrote: > > On 23 July 2016 at 22:26, Ronald Oussoren wrote: >> I’m currently working on getting the patch in 18181 up-to-date w.r.t. the >> current trunk, the patch in the issue no longer applies cleanly. After that >> I’ll try to think up some tests tha

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-07-24 Thread Nick Coghlan
On 23 July 2016 at 22:26, Ronald Oussoren wrote: > I’m currently working on getting the patch in 18181 up-to-date w.r.t. the > current trunk, the patch in the issue no longer applies cleanly. After that > I’ll try to think up some tests that seriously try to break the new > behaviour, and I want t

Re: [Python-Dev] PEP 447: Add __getdescriptor__ to metaclasses

2016-07-23 Thread Brett Cannon
On Sat, 23 Jul 2016 at 05:27 Ronald Oussoren wrote: > [SNIP] > > What is the best way forward after that? As before this is a change in > behavior that, unsurprisingly, few core devs appear to be comfortable with > evaluating, combined with new functionality that will likely see little use > be