Difference between type and class

[Nikolaus Rath]

Hello,

Can someone explain to me the difference between a type and a class?
After reading http://www.cafepy.com/article/python_types_and_objects/
it seems to me that classes and types are actually the same thing:

- both are instances of a metaclass, and the same metaclass ('type')
can instantiate both classes and types.
- both can be instantiated and yield an "ordinary" object
- I can even inherit from a type and get a class

So why does Python distinguish between e.g. the type 'int' and the
class 'myclass'? Why can't I say that 'int' is a class and 'myclass'
is a type?

I hope I have managed to get across the point of my confusion...
Thanks in advance,

-Nikolaus

--
»It is not worth an intelligent man's time to be in the majority.
By definition, there are already enough people to do that.«
-J.H. Hardy

PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C

[Gabriel Genellina]

En Thu, 31 Jul 2008 09:30:19 -0300, Nikolaus Rath <Ni******@rath. org>
escribi�:

oj <oj*****@gmail. comwrites:

>On Jul 31, 11:37Â*am, Nikolaus Rath <Nikol...@rath. orgwrote:

>>So why does Python distinguish between e.g. the type 'int' and the
class 'myclass'? Why can't I say that 'int' is a class and 'myclass'
is a type?

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:

>>>class int_class(objec t):

... pass
...

>>>int_class

<class '__main__.int_c lass'>

>>>int

<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

--
Gabriel Genellina

[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.

>>class C(): pass

....

>>c=C()

>>type(C)

<type 'classobj'>

>>type(c)

<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.

>>class C(): pass # 3.0, in 2.x, class c(object)

>>c=C()
type(C)

<class 'type'# same as

>type(int)

<class 'type'>

>>type(c)

<class '__main__.C'>

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).

>>int

<class 'int'>

>>c

<class '__main__.c'>

>>import itertools as i
i.product

<class 'itertools.prod uct'>

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