[issue1294232] Error in metaclass search order

Serhiy Storchaka added the comment: Python 2.7 is no longer supported. -- nosy: +serhiy.storchaka resolution: -> fixed stage: needs patch -> resolved status: open -> closed ___ Python tracker

[issue1294232] Error in metaclass search order

Changes by Bruno Dupuis bdup...@lisael.org: -- nosy: +bruno.dupuis ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list

[issue1294232] Error in metaclass search order

Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: ncoghlan - ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___

[issue1294232] Error in metaclass search order

Changes by Barry A. Warsaw ba...@python.org: -- nosy: +barry ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___ Python-bugs-list

[issue1294232] Error in metaclass search order

Florent Xicluna florent.xicl...@gmail.com added the comment: After changeset c72063032a7a I get this complain: Python/bltinmodule.c: In function ‘builtin___build_class__’: Python/bltinmodule.c:43: warning: unused variable ‘nbases’ -- nosy: +flox ___

[issue1294232] Error in metaclass search order

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset b9bb9340eb0c by Florent Xicluna in branch 'default': Merge 3.2 (linked to issue #1294232) http://hg.python.org/cpython/rev/b9bb9340eb0c -- ___ Python tracker

[issue1294232] Error in metaclass search order

Roundup Robot devn...@psf.upfronthosting.co.za added the comment: New changeset c2a89b509be4 by Nick Coghlan in branch '3.2': Issue 1294232: Fix errors in metaclass calculation affecting some cases of metaclass inheritance. Patch by Daniel Urban. http://hg.python.org/cpython/rev/c2a89b509be4

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Fix has been applied to 3.x and hence will be in 3.3 and the next 3.2 release. I have adjusted the issue metadata to reflect the fact 2,7 still exhibits the problem, but the patch requires significant work to account for the 3.x vs 2.x

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Looking at Daniel's updated patch is still on my to-do list, but I won't object if anyone else wants to take this forward (it will be at least a few weeks before I get to it). -- ___ Python tracker

[issue1294232] Error in metaclass search order

Changes by Meador Inge mead...@gmail.com: -- nosy: +meador.inge stage: test needed - patch review ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___

[issue1294232] Error in metaclass search order

Changes by Eric Snow ericsnowcurren...@gmail.com: -- nosy: +ericsnow ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___

[issue1294232] Error in metaclass search order

Changes by Nick Coghlan ncogh...@gmail.com: -- assignee: - ncoghlan ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: 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

[issue1294232] Error in metaclass search order

Guido van Rossum gu...@python.org added the comment: Thanks for diving deep! How much of this can we claim as a bug and how much as a feature? -- ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: As near as I can tell, the only visible behavioural change with Daniel's patch (updated as per my last comment) will be that the two error cases noted above (i.e. when an explicit metaclass or the first parent type's metaclass is not the most

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Commenting on the latest patch here, since the Rietveld integration isn't coping with the hg extdiff output (I would guess that the revision numbers in the pathnames are confusing the script that attempts to determine the base revision).

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: I'm attaching the updated patch. Changes: - Special casing objects we can't do the metaclass computation for. - Tests for these. - Adding tests for the order of __new__ calls. The special case isn't just checking if the object is a class,

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: 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',

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: 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,

[issue1294232] Error in metaclass search order

Changes by Daniel Urban urban.dani...@gmail.com: Removed file: http://bugs.python.org/file21755/issue11256_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___

[issue1294232] Error in metaclass search order

Changes by Daniel Urban urban.dani...@gmail.com: Added file: http://bugs.python.org/file21756/issue_1294232_4.patch ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: That may be, but with my latest patch, this works (func is a function): class X(metaclass=func): pass But this blows up with a TypeError: class X(object, metaclass=func): pass Is this the desired behaviour? Or should we disallow

[issue1294232] Error in metaclass search order

Guido van Rossum gu...@python.org added the comment: class X(metaclass=func) should definitely continue to work; that is a long-standing (if relatively unknown, and very advanced) feature. In fact, metaclasses have their origins in this, via the Don Beaudry hook -- see

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Yep, the leading underscore and the fact you added it to a block of code that is skipped when Py_LIMITED_API is defined makes it OK to include the prototype in object.h. However, I would suggest _PyType_CalculateMetaclass as the name -

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Removed 2.7 from the affected versions - with neither __build_class__ nor __prepare__ in 2.x, there's no alternate metaclass calculation to go wrong. This should definitely be fixed for the final 3.1 release and for 3.2 though. An updated

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: Sorry, my last review wasn't right and the patch is incorrect as it stands. After digging a little deeper, there is still a case that isn't covered correctly in __build_class__. Specifically, the case where the most derived class has a

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: Thanks for the review! I've updated my patch: - renamed it to _PyType_CalculateMetaclass - in __build_class__ call it even when a metaclass is declared - added a test for this case (which fails with my previous patch) However I noticed

[issue1294232] Error in metaclass search order

Nick Coghlan ncogh...@gmail.com added the comment: This last point sounds like an error in PEP 3115 rather than an error in the implementation - as the exception says, the metaclass of a derived class must be the same as or a subclass of the metaclasses of all of its bases. Since that rule

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: The attached patch seems to correct this issue. It contains the test attached yesterday, and it passes now. I factored out the winner calculation from type_new to a new _PyType_CalculateWinner function, and type_new calls this. I've

[issue1294232] Error in metaclass search order

Terry J. Reedy tjre...@udel.edu added the comment: I would make the same guess about 'winner calculation'. I am surprised that the class statement does not result in the same calculation (why else would type_new do it). Perhaps __build_class__ (which I have not read) should either call

[issue1294232] Error in metaclass search order

Changes by Terry J. Reedy tjre...@udel.edu: -- versions: +Python 3.3 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___ ___

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: The attached test case currently fails. I'll try to make a patch soon. Perhaps __build_class__ (which I have not read) should either call type_new or a new function with the winner calculation factored out of type_new. Yeah, that's

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: It seems, that this possible problem already came up when __build_class__ got implemented, see issue1681101. The second and third version of the patch at this issue (file7874 and file7875) contains a comment: XXX Should we do the winner

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: What also worries me is the difference between the class statement and the type() function. I think the reason of this is that the class statement uses the __build_class__ builtin function. This function determines the metaclass to use

[issue1294232] Error in metaclass search order

Amaury Forgeot d'Arc amaur...@gmail.com added the comment: What also worries me is the difference between the class statement and the type() function. class M_A(type): def __new__(mcls, name, bases, ns): print('M_A.__new__', mcls, name, bases) return super().__new__(mcls,

[issue1294232] Error in metaclass search order

Daniel Urban urban.dani...@gmail.com added the comment: I think the situation is a bit more complicated. Here is the example described by Pedro Werneck (this is py3k, but its essentially the same in 2.x): class M_A(type): ... def __new__(mcls, name, bases, ns): ...

[issue1294232] Error in metaclass search order

Terry J. Reedy tjre...@udel.edu added the comment: Is the 3.1/2 doc still lacking in this area? -- nosy: +terry.reedy versions: +Python 2.7, Python 3.1, Python 3.2 -Python 2.6 ___ Python tracker rep...@bugs.python.org

[issue1294232] Error in metaclass search order

Changes by Terry J. Reedy tjre...@udel.edu: -- assignee: - georg.brandl nosy: +georg.brandl ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232 ___

[issue1294232] Error in metaclass search order

Changes by Daniel Diniz aja...@gmail.com: -- priority: normal - low stage: - test needed type: - feature request versions: +Python 2.6 -Python 2.4 ___ Python tracker rep...@bugs.python.org http://bugs.python.org/issue1294232