On Thu, Oct 13, 2016 at 7:15 PM Neil Girdhar <mistersh...@gmail.com> wrote:
> That's fair. However, the documentation should at least be repaired by
> replacing section 126.96.36.199 with:
> "The metaclass of a class definition is selected from the explicitly
> specified metaclass (if any) and the metaclasses (i.e. type(cls)) of all
> specified base classes. The most derived metaclass is one which is a
> subtype of all of these candidate metaclasses. If none of the candidate
> metaclasses meets that criterion, then the class definition will fail with
> TypeError. If provided, the explicit metaclass must be a callable accepting
> the positional arguments (name, bases, _dict)."
> This is because something happened along the way and Objects/typeobject.c:
> type_new no longer coincides with Lib/types.py:new_class. The Python
> version conditionally calls _calculate_meta whereas the C version calls it
> unconditionally. I consider the C implementation to be the "correct"
> On Thu, Oct 13, 2016 at 5:41 PM Steven D'Aprano <st...@pearwood.info>
> On Thu, Oct 13, 2016 at 01:46:34PM -0700, Neil Girdhar wrote:
> > If provided, the explicit metaclass must be an instance of
> > type()."
> -1 for pointless breakage.
> The metaclass has always been permitted to be any callable. You haven't
> given any good reason for gratuitously changing this.
> Python-ideas mailing list
> Code of Conduct: http://python.org/psf/codeofconduct/
> You received this message because you are subscribed to a topic in the
> Google Groups "python-ideas" group.
> To unsubscribe from this topic, visit
> To unsubscribe from this group and all its topics, send an email to
> For more options, visit https://groups.google.com/d/optout.
Python-ideas mailing list
Code of Conduct: http://python.org/psf/codeofconduct/