Re:In CPython, types implemented in C are part of the type tree
by legerdemain on Thursday December 24, 2020 @02:41PM
(#25530720)
Python2:
Python3:
[ Parent
| on HN ]
Re:In CPython, types implemented in C are part of the type tree
by siebenmann on Thursday December 24, 2020 @02:55PM
(#25530857)
The 'class' versus 'type' distinction here is actually arbitrary. The same C level code is responsible for the message that you get from 'type(whatever)' in both Python 2 and Python 3, but in Python 2 it drew a distinction between heap-allocated things (which were reported as 'class') and things that were not heap allocated (which were reported as 'type'). Non heap allocated things had to be created in C; heap allocated things were usually implemented in Python and were usually made with 'class X(base): ...'.
(This change was introduced in Python 3.0a5, bug #2565. Looking at the bug, this is a followup of making the type() of new style classes be reported as 'class ...', but preserving old behavior of type() for built-ins, done in 2001.)
Re:In CPython, types implemented in C are part of the type tree
by chrismorgan on Thursday December 24, 2020 @02:54PM
(#25530848)
Ah, gotcha. But I don’t think that that’s actually a difference—it’s just a slight terminology change around “type” and “class”, which I think may have been related to tidying up old-style classes. (That is: yeah, if you’re comparing old-style classes, it may have been a difference (I’m not certain), but I believe it’s completely superficial once you’re comparing the recommended form of classes for the last quite a few years of Python 2.)
Re:In CPython, types implemented in C are part of the type tree
by eesmith on Thursday December 24, 2020 @03:12PM
(#25530988)
I agree.
I'm pretty sure the word "class" here comes from the repr for types, in Objects/typeobject.c :
static PyObject *
type_repr(PyTypeObject *type)
{
...
if (mod != NULL && !_PyUnicode_EqualToASCIIId(mod, &PyId_builtins))
rtn = PyUnicode_FromFormat("<class '%U.%U'>", mod, name);
else
rtn = PyUnicode_FromFormat("<class '%s'>", type->tp_name);
...
which is used later on when defining the "type" type: PyTypeObject PyType_Type = {
PyVarObject_HEAD_INIT(&PyType_Type, 0)
"type", /* tp_name */
...
(reprfunc)type_repr, /* tp_repr */
That is, Python 3 has no actual "class" type, so it's not correct to say that '"type" is an instance of "class."'(I could be wrong - I'm no expert at the Python internals.)
Re:In CPython, types implemented in C are part of the type tree
by quietbritishjim on Friday December 25, 2020 @08:01AM
(#25536217)
Looks like a slight difference in debugging text printed by a single function, not something fundamental about the whole type system.