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-21.22:35:34
SpamBayes Score 1.2486722e-06
Marked as misclassified No
Message-id <1303425335.3.0.887930178781.issue1294232@psf.upfronthosting.co.za>
In-reply-to
Content
I've just realized, that my patch still breaks a case, that previously worked: when the bases are not classes.

This works in 3.2, but not with my patch:

>>> class Foo:  # not a subclass of type!
...     def __new__(mcls, name='foo', bases=(), namespace={}):
...             self = super().__new__(mcls)
...             self.name = name
...             return self
... 
>>> foo1 = Foo('foo1')
>>> foo1.name
'foo1'
>>> 
>>> foo2 = Foo('foo2')
>>> foo2.name
'foo2'
>>> 
>>> class foo3(foo1, foo2):pass
... 
>>> foo3
<__main__.Foo object at 0xb74aa96c>
>>> foo3.name
'foo3'

This raises a TypeError: "metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases".  In this case the *type* of all of its bases is the same (Foo), but that type is not a metaclass, but a regular class.

Right now I don't know if this is a real problem, or how to solve it.
History
Date User Action Args
2011-04-21 22:35:35daniel.urbansetrecipients: + daniel.urban, gvanrossum, georg.brandl, terry.reedy, amaury.forgeotdarc, ncoghlan, rodsenra, pwerneck, benjamin.peterson
2011-04-21 22:35:35daniel.urbansetmessageid: <1303425335.3.0.887930178781.issue1294232@psf.upfronthosting.co.za>
2011-04-21 22:35:34daniel.urbanlinkissue1294232 messages
2011-04-21 22:35:34daniel.urbancreate