Currently type_new() in Objects/typeobject.c enforces a restriction that the namespace be a dict or dict subclass.  It does this via the PyArg_ParseTupleAndKeywords() call there.

This means that valid mappings may not be used even though they should work just fine.  A demonstration of the problem is below.

I've attached a patch that relaxes this restriction.  Should we also add a note in the docs that type() will take anything for namespace that dict() will take?

Demonstration
-------------

class Meta(type):
    @classmethod
    def __prepare__(cls, name, bases, **kwargs):
        return ClassMapping()

from collections import MutableMapping
class ClassMapping(MutableMapping):
    def __init__(self, *args, **kwargs):
        self._dict = dict(*args, **kwargs)
    def __len__(self):
      return len(self._dict)
    def __iter__(self):
        return iter(self._dict)
    def __getitem__(self, key):
        return self._dict[key]
    def __setitem__(self, key, value):
        self._dict[key] = value
    def __delitem__(self, key):
        del self._dict[key]

>>> class X(metaclass=Meta):
...     pass
...
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: type() argument 3 must be dict, not ClassMapping

Are you sure that non-dicts work fine? ISTM that there is quite some code that relies on tp_dict being a dict-or-subdict instance, e.g. in typeobject.c:type_module,type_get_doc etc.

Sorry I wasn't clear.  Later in type.__new__() it copies that passed namespace into a new dict (see issue #17422).  So as long as the namespace argument is a valid argument to dict(), it's going to work fine.  We don't need the extra explicit check performed by PyArg_ParseTupleAndKeywords().

Eric and I discussed this, and I've come to the conclusion that the check doesn't serve much purpose at this point.

I initially thought it conveyed useful information about the runtime behavioural restriction, but it doesn't even do that correctly, as dict subclasses (like collections.OrderedDict) will pass the check but will also be copied into a vanilla dict instance.

However, we definitely shouldn't drop it until the copying behaviour is properly documented, so I've added #17422 as an explicit dependency.

> Are you sure that non-dicts work fine?

They don't. See issue31588.

In my mind this seems like a bug. PEP 3115 states:
'''
__prepare__ returns a dictionary-like object which is used to store the class member definitions during evaluation of the class body. In other words, the class body is evaluated as a function block (just like it is now), except that the local variables dictionary is replaced by the dictionary returned from __prepare__. This dictionary object can be a regular dictionary or a custom mapping type.
'''