On Sat, Apr 21, 2012 at 11:30 AM, Nick Coghlan wrote:
> On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby wrote:
> > Personally, I think __build_class__ should be explicitly exposed and
> > supported, if for no other reason than that it allows one to re-implement
> > old-style __metaclass__ support in 2.
On Sun, Apr 22, 2012 at 12:55 AM, PJ Eby wrote:
> (Sorry I'm so late to this discussion.)
>
> I think that it's important to take into account the fact that PEP 3115
> doesn't require namespaces to implement anything more than __setitem__ and
> __getitem__ (with the latter not even needing to do a
(Sorry I'm so late to this discussion.)
I think that it's important to take into account the fact that PEP 3115
doesn't require namespaces to implement anything more than __setitem__ and
__getitem__ (with the latter not even needing to do anything but raise
KeyError).
Among other things, this mea
On Mon, Apr 16, 2012 at 04:17, Nick Coghlan wrote:
> Sure, just create a new tracker issue and assign it to me. You already
> know better than most what the _prepare() step needs to do :)
I've created http://bugs.python.org/issue14588, and attached the first
version of a patch. I can't assign it
On Mon, Apr 16, 2012 at 5:34 AM, Daniel Urban wrote:
> On Sun, Apr 15, 2012 at 13:48, Nick Coghlan wrote:
>> /me pages thoughts from 12 months ago back into brain...
>
> Sorry about that, I planned to do this earlier...
No worries - good to have someone following up on it, since it had
completel
On Sun, Apr 15, 2012 at 13:48, Nick Coghlan wrote:
> /me pages thoughts from 12 months ago back into brain...
Sorry about that, I planned to do this earlier...
> On Sun, Apr 15, 2012 at 7:36 PM, Daniel Urban wrote:
>> On Tue, Apr 19, 2011 at 16:10, Nick Coghlan wrote:
>>> Initially I was going
/me pages thoughts from 12 months ago back into brain...
On Sun, Apr 15, 2012 at 7:36 PM, Daniel Urban wrote:
> On Tue, Apr 19, 2011 at 16:10, Nick Coghlan wrote:
>> Initially I was going to suggest making __build_class__ part of the
>> language definition rather than a CPython implementation de
On Tue, Apr 19, 2011 at 16:10, Nick Coghlan wrote:
> In reviewing a fix for the metaclass calculation in __build_class__
> [1], I realised that PEP 3115 poses a potential problem for the common
> practice of using "type(name, bases, ns)" for dynamic class creation.
>
> Specifically, if one of the
In reviewing a fix for the metaclass calculation in __build_class__
[1], I realised that PEP 3115 poses a potential problem for the common
practice of using "type(name, bases, ns)" for dynamic class creation.
Specifically, if one of the base classes has a metaclass with a
significant __prepare__()
