class MetaFoo(type): def __new__(cls, name, bases, thedict): print "MetaFoo new" return super(MetaFoo,cls).__new__(cls, name, bases, thedict) def callnew(cls, *args, **kwargs): return super(MetaFoo,cls).__new__(*args, **kwargs) MetaFoo.callnew = classmethod(callnew) Foo = MetaFoo("Foo", (object,), {}) FooChildSneaky = MetaFoo.callnew(MetaFoo, "FooChildSneaky", (Foo,), {}) FooChildSneaky.__class__ -> FooChildSneaky = MetaFoo.callnew(type, "FooChildSneaky", (Foo,), {}) -> MetaFoo new <-- WTFPYTHON?! FooChildSneaky.__class__ -> # also works, without the classmethod. FooChildSneaky = type.__new__(MetaFoo, "FooChildSneaky", (Foo,), {}) FooChildSneaky.__class__ -> notes: the 'callnew' dance I did was meant to catch lurking special cases but didn't manage to find any. the first arument to type.__new__ is the metaclass of what you are creating. The metaclass in .__class__ is important to what's discovered here. I never re-investigated when __metaclass__ is actually used. The following error, which I was onnly able to achieve by subclassing 'type' with two different metaclasses, explains what I think Python is trying to achieve: TypeError: metaclass conflict: the metaclass of a derived class must be a (non-strict) subclass of the metaclasses of all its bases but if you pass 'type' as the metaclass in the first argument to type.__new__ (meaning, you don't want a metaclass, you want an object like normal objects), then type.__new__ seems to infer a metaclass from the base classes given *AND* not create the class itself but let the metaclass do so by, something like, calling '(*args[1:])'. note the first and third FooChildSneaky I created above has evaded Python's rule because although it claims to have a metaclass of MetaFoo, the MetaFoo.__new__ static method wasn't used to create it! Example of the magical behavior: class MetaFoo(type): def __new__(cls, name, bases, thedict): print "MetaFoo new" return super(MetaFoo,cls).__new__(cls, name, bases, thedict) Foo = MetaFoo("Foo", (object,), {}) Foo.__class__ def __new__(cls, name, bases, thedict): print "MetaFoo new" return super(MetaFoo,cls).__new__(type, name, bases, thedict) __new__ = staticmethod(__new__) MetaFoo.__new__ = __new__ Bar = MetaFoo("Foo", (object,), {}) Bar.__class__ FooChildSneaky = type("FooChildSneaky", (Foo,), {}) -> RuntimeError: maximum recursion depth exceeded while calling a Python object Here, we show three things. We show that even though __new__ is a staticmethod, it's getting the class prepended as an argument thanks to another aspect of the __new__ specialcase Guido mentioned in the metaclass paper: http://www.python.org/download/releases/2.2.1/descrintro/#metaclasses http://www.python.org/dev/peps/pep-3115/ We show a Bar that's got 'type' for its metaclass instead of MetaFoo even though it's been made by the MetaFoo factory, thanks to our call to the superclass __new__'s first argument. And we see that, even from within MetaFoo, when type.__new__ gets called with 'type' as the first argument, it disobeys you and looks at the base classes' metaclasses (in this case, Foo's), then passes off creation to that metaclass instead of doing it itself. so, you can see how we can use the mechanism type.__new__ is using to terminate the recursion, to skip invoking the __new__ functions of our proper metaclass! Q. Why was I forced to care about this? A. django.forms.models.ModelFormMetaclass has an inconvenient __new__ function. I want to subclass a ModelForm without letting the metaclass's __new__ run and fill my subclass up with default empty configuration attributes overriding the working configuration attributes of its ancestor. the purpose of ModelFormMetaclass.__new__ is to transform things in the __dict__ of the new class being created. if ModelFormMetaclass.__new__ had been written in a very careful subclass-friendly way so that the inheritance of __dict__ behaved the same way before and after the translation, I could leave the metaclass of ModelForm ancestors alone. This might not be possible because I think part of the translation's aim is to provide complicated defaults. If it were possible, it might not be readable and maintainable. I don't know. I haven't tried. if ModelFormMetaclass.__new__ had deviated from Guido's metaclass instructions and used 'type' as the first argument to the superclass __new__, like I did with Bar, then it would instantiate ModelForm classes that had 'type' as their metaclass instead of ModelFormMetaclass, it would still work without the recursion above, and I would only get __new__'s translation if I said '__metaclass__ = ModelFormMetaclass' when defining my user forms. But django wants me to get the translation whenever I subclass ModelForm, without having to learn about metaclasses. django says in forms/models.py: class ModelForm(BaseModelForm): __metaclass__ = ModelFormMetaclass and wants the user of newforms to say something like: from usarproject.usarapp.models import * from django import forms class UsarForm(forms.ModelForm): class Meta(object): model = UsarModelTable def formfield_callback(f): return f.formfield() usarform=UsarForm() usarform.as_p() so the complicated __new__ still gets invoked to make UsarForm, which you can see is happening from the fact formfield_callback is written in this bogus way with no 'self' argument and no @staticmethod either. Django's relying on the 'type' special case to infer UsarForm's metaclass from its bases' metaclasses. but we can short-circuit it by calling type.__new__ by hand and setting the first argument to ModelFormMetaClass, to pretend to be already within the ModelFormMetaclass.__new__ when we're not.