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 ncoghlan
Recipients bup, ncoghlan, xiang.zhang
Date 2017-03-30.14:48:55
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
Interestingly, even `types.new_class` misbehaves in this case:

>>> def mydec(cls):
...     return types.new_class(cls.__name__, cls.__bases__, exec_body=lambda ns: ns.update(cls.__dict__))
>>> @mydec
... class MyList(list):
...     def insert(self, idx, obj):
...         super().insert(idx, obj)
>>> MyList().insert(0, 1)
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 4, in insert
TypeError: super(type, obj): obj must be an instance or subtype of type

The error message is confusing here because it's using 'type' as a metavariable to refer to the first argument of super(), *not* to the builtin called "type".

If we poke around in the MyList.insert closure, we can see the origin of the problem:

>>> MyList.insert.__closure__[0].cell_contents
<class '__main__.MyList'>
>>> MyList.insert.__closure__[0].cell_contents is MyList

The class cell is still bound to the originally created class object, but the decorator threw that away and returned a completely different object. As a result, the "self" passed to the bound method is *not* an instance of the type stored in the "__class__" cell, and super() complains.

Given that super() doesn't take keyword arguments, perhaps we should propose on python-dev that "type" be changed to "starting_type" in the super() error messages and documentation?
Date User Action Args
2017-03-30 14:48:55ncoghlansetrecipients: + ncoghlan, xiang.zhang, bup
2017-03-30 14:48:55ncoghlansetmessageid: <>
2017-03-30 14:48:55ncoghlanlinkissue29944 messages
2017-03-30 14:48:55ncoghlancreate