This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author ncoghlan
Recipients amaury.forgeotdarc, benjamin.peterson, daniel.urban, georg.brandl, gvanrossum, ncoghlan, pwerneck, rodsenra, terry.reedy
Date 2011-04-21.14:11:29
SpamBayes Score 0.00021069782
Marked as misclassified No
Message-id <1303395090.87.0.854813703923.issue1294232@psf.upfronthosting.co.za>
In-reply-to
Content
I think PEP 3115 is OK - the error about all metaclasses inheriting from type was a mistake on my part (I thought the ability to create non-type metaclasses went away along with old-style classes, but I was simply wrong on that point).

That got me curious as to how the explicit inheritance from object + explicit non-type metaclass case was working in 2.7, and it turns out it *does* share the same initial metaclass determination error as 3.x - it is just that build_class() is embedded in ceval.c rather than being published as a builtin.

So I have two conclusions:

- to match existing behaviour when __metaclass__ is not an instance of type(), __build_class__ still needs one special case where it bypasses the normal metaclass calculation: when an explicit metaclass exists and is *not* an instance of type.

- after we get 3.x sorted, we will want to backport this to the ceval version of build_class() in 2.7
History
Date User Action Args
2011-04-21 14:11:30ncoghlansetrecipients: + ncoghlan, gvanrossum, georg.brandl, terry.reedy, amaury.forgeotdarc, rodsenra, pwerneck, benjamin.peterson, daniel.urban
2011-04-21 14:11:30ncoghlansetmessageid: <1303395090.87.0.854813703923.issue1294232@psf.upfronthosting.co.za>
2011-04-21 14:11:30ncoghlanlinkissue1294232 messages
2011-04-21 14:11:29ncoghlancreate