Difference between type and class

[Terry Reedy]

Of course I wanted to write `class A(object)', but I keep forgetting
this one because I'm still used to the old ways...

Will this disappear in Python 3.0., i.e. can you again simply write
class A:
and inherit from object automagically?

Yes.
IDLE 3.0b2(<class 'object'>,)

3.0 is really a nicer version. Once the final release is out, the main
reason to stick with 2.x for new code will be if it depends on
third-party code (including your own ;-) that has not been upgraded.

 

[Gabriel Genellina]

I might be wrong here, but I think the point is that there is no
distinction. A class (lets call it SomeClass for this example) is an
object of type 'type', and an instance of a class is an object of type
'SomeClass'.

But there seems to be a distinction:
... pass
...<type 'int'>
[...]
If there is no distinction, how does the Python interpreter know when
to print 'class' and when to print 'type'?

If it helps you to understand the issue, in Python 3.0 that difference is
gone - the word "class" is used on both cases. See
http://bugs.python.org/issue2565

 

[Terry Reedy]

Gabriel Genellina wrote:

A decade ago, in 1.x, 'types' were built-in classes. They were
instances of class 'type'. 'Classes' were user-defined classes. They
were instances of (built-in) class 'classob'. User classes had the same
status as instances of any other built-in class. They could only
inherit from other instances of 'UserClass'. Instances of user classes
were actually instances of built-in class 'instance'. They could not be
instances of the user class because user classes were, in a sense, not
really classes, just instances of 'classob' that emulated 'real' classes.
<type 'instance'>

Many users found the distinction between built-in classes and user
classes confusing and limiting. Users wanted to be able to use built-in
classes as base classes for user classes. So in 2.2 'object' was added
as the base-class for all built-in classes and user-classes with
'object' in the base-class tree became instances of type (or of some
other meta-class derived from type) instead of classob. But the
representation of new-style classes matched that of old-style classes
rather than that of the other instances of 'type' that happened to be
built in.

In 3.0, built-in classes 'classob' and 'instance' are gone, along with
the confusion of having two categories of user classes along with an
apparently separate category of built-in classes. User-classes are real
classes on a par with C-coded classes.

If it helps you to understand the issue, in Python 3.0 that
difference is gone - the word "class" is used on both cases. See
http://bugs.python.org/issue2565

The only visible difference now (in 3.0) is that C-coded built-in
classes that are present as startup and which do not live in any
particular module do not have a module name as part of their
representation. Imported C-coded classes show no difference (and
indeed, in other implementations, they might be coded in Python or ??
rather than C).
<class 'itertools.product'>

I believe this should mean that if one write a module in Python and
later rewrites part of it in C for speed, with identical API, the change
of implementation will otherwise be transparent to user code and users,
as it ought to be.

Terry Jan Reedy