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 daniel.urban
Recipients amaury.forgeotdarc, benjamin.peterson, daniel.urban, georg.brandl, gvanrossum, ncoghlan, pwerneck, rodsenra, terry.reedy
Date 2011-04-22.05:41:23
SpamBayes Score 1.85408e-07
Marked as misclassified No
Message-id <1303450886.25.0.131529016318.issue1294232@psf.upfronthosting.co.za>
In-reply-to
Content
Okay, probably the check in my previous patch was too strict (sorry for the noise).  I'm attaching an updated patch again.  Now the algorithm in __build_class__ is this:

1. If an object is explicitly given with the metaclass keyword, that is the "starting metaclass".
2. Else if there are bases, the type of the first base is the starting metaclass (note, that this possibly will be replaced later, but before the __prepare__ call).
3. Else the starting metaclass is type.

4. If the starting metaclass is a class, do the metaclass calculation, so the starting metaclass may be replaced with its most derived descendant.
5. Else we cannot do the metaclass calculation, so use the starting metaclass as is.

There are also tests for these cases, and the example in msg134256 now works too.
History
Date User Action Args
2011-04-22 05:41:26daniel.urbansetrecipients: + daniel.urban, gvanrossum, georg.brandl, terry.reedy, amaury.forgeotdarc, ncoghlan, rodsenra, pwerneck, benjamin.peterson
2011-04-22 05:41:26daniel.urbansetmessageid: <1303450886.25.0.131529016318.issue1294232@psf.upfronthosting.co.za>
2011-04-22 05:41:24daniel.urbanlinkissue1294232 messages
2011-04-22 05:41:24daniel.urbancreate