Unhelpful error message when one calls a subclass of type with a custom metaclass

[pppery]

BPO	27157
Nosy	@gvanrossum, @rhettinger, @stevendaprano, @bitdancer, @berkerpeksag, @serhiy-storchaka, @eryksun, @pppery, @Vgr255
Files	type_one_argument_1.patch type_one_argument_2.patch type_one_argument_3.patch type_one_argument_4.patch type_one_argument_5.patch

^{Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.}

Show more details

GitHub fields:

assignee = None
closed_at = <Date 2016-08-19.08:04:09.342>
created_at = <Date 2016-05-29.22:46:08.510>
labels = ['interpreter-core', 'type-bug']
title = 'Unhelpful error message when one calls a subclass of type with a custom metaclass'
updated_at = <Date 2016-08-19.08:04:09.341>
user = 'https://github.com/pppery'

bugs.python.org fields:

activity = <Date 2016-08-19.08:04:09.341>
actor = 'berker.peksag'
assignee = 'none'
closed = True
closed_date = <Date 2016-08-19.08:04:09.342>
closer = 'berker.peksag'
components = ['Interpreter Core']
creation = <Date 2016-05-29.22:46:08.510>
creator = 'ppperry'
dependencies = []
files = ['43054', '43056', '43060', '43062', '44109']
hgrepos = []
issue_num = 27157
keywords = ['patch']
message_count = 31.0
messages = ['266643', '266645', '266649', '266650', '266651', '266652', '266653', '266654', '266660', '266662', '266663', '266666', '266667', '266673', '266676', '266677', '266684', '266693', '266701', '266702', '266705', '266706', '266712', '266722', '266726', '266728', '266729', '270348', '272697', '273089', '273090']
nosy_count = 10.0
nosy_names = ['gvanrossum', 'rhettinger', 'steven.daprano', 'r.david.murray', 'python-dev', 'berker.peksag', 'serhiy.storchaka', 'eryksun', 'ppperry', 'abarry']
pr_nums = []
priority = 'normal'
resolution = 'fixed'
stage = 'resolved'
status = 'closed'
superseder = None
type = 'behavior'
url = 'https://bugs.python.org/issue27157'
versions = ['Python 3.6']

[pppery]

>>>class x(type):pass
>>> x(x)
Traceback (most recent call last):
  File "<pyshell#335>", line 1, in <module>
    x(x)
TypeError: type() takes 1 or 3 arguments

I am giving it one argument, and yet it's complaining that type expects one or three arguments. How unhelpful.

[Vgr255]

Works for me:

>>> class X(type): pass
...
>>> X(X)
<class 'type'>

[pppery]

This issue only happens when the type in question has a custom metaclass:

>>> class meta(type):pass
>>> class X(type,metaclass=meta):pass
>>> X(X)
[Same unhelpful TypeError]

[pppery]

Also happens on 2.7, although you have to declare the metaclass using __metaclass__ = meta instead.

[Vgr255]

In Objects/typeobject.c#L2290, the code checks that the (meta?)class is exactly type and that there's one argument, then returns Py_TYPE(x). Subclasses of type allowing a single argument is a side-effect of not overriding new, not a documented feature.

Changing the call from PyType_CheckExact to PyType_Check makes it work, but I'm assuming there may be something I didn't think of. Or maybe there isn't, but either way, I don't consider that this is worth fixing -- if you want to call your subclass with only one argument, override new and do the logic in there. And if you want the type of an object, use type directly.

Also, there may be performance concerns here. type is heavily optimized in many places; I thought that PyType_Check called Python code, but after checking the macro definitions and testing a bit, it turns out I'm wrong. But if there is a negative performance impact, this probably can't go in -- this check runs everytime that type() is called, no matter how many arguments, and including in class creation; that's also probably why PyType_CheckExact was chosen to begin with.

[pppery]

Further testing reveals that this issue has nothing to do with metaclasses:

>>class X(type):pass
>>X()(X)

raises the same TypeError.
Even if the possibly dubious feature of being able to call instances of subclasses of type with one argument is rejected, the error message should definitely be improved. It is ridiculously unhelpful.

[pppery]

Ignore the first part of my previous comment; I improperly tested that.

[Vgr255]

Yes, that would be preferable. The error message is at Objects/typeobject.c#l2301, but keep in mind that this message is shown for both faulty calls to type() as well as any of its subclasses that don't override __new__, and I'm lukewarm on adding e.g. a PyType_Check call before that; might as well replace the PyType_CheckExact call and make this work. I'm not knowledgeable enough in that field though, you'll need a core dev's advice.