Difference between type and class

[Nikolaus Rath]

Re: Difference between type and class

Miles <semanticist@gm ail.comwrites:

On Thu, Jul 31, 2008 at 1:59 PM, Nikolaus Rath wrote:

>If it is just a matter of different rendering, what's the reason for
>doing it like that? Wouldn't it be more consistent and straightforward
>to denote builtin types as classes as well?

>
Yes, and in Python 3, it will be so:
>

[..]

http://svn.python.org/view?rev=23331&view=rev

That makes matters absolutely clear. Thanks a lot. No more questions
from my side ;-).


Best,

-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

[Nikolaus Rath]

Re: Difference between type and class

Steven D'Aprano <steve@REMOVE-THIS-cybersource.com .auwrites:

So, to the Original Poster:
>
In Python, new-style classes and types are the same, but it is
traditional to refer to customer objects as "class" and built-in
objects as "types". Old-style classes are different, but you are
discouraged from using old-style classes unless you have a specific
reason for needing them (e.g. backwards compatibility).

I see. Thanks a lot for the explanation.


Best,

-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

[Thomas Troeger]

Re: Difference between type and class

Steven D'Aprano wrote:

>class A:
> def bar(self):
> print "A"

>
>
Alas, you've chosen the worst-possible example to "clarify" matters,
because old-style classic classes are *not* unified with types, and will
disappear in the future:

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? That would be nice since that's
what most people probably want.

[Matthew Woodcraft]

Re: Difference between type and class

Thomas Troeger <thomas.troeger .ext@siemens.co mwrote:

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

Short answer: yes.

-M-

[Terry Reedy]

Re: Difference between type and class



Thomas Troeger wrote:

Steven D'Aprano wrote:

>>class A:
>> def bar(self):
>> print "A"

>>
>>
>Alas, you've chosen the worst-possible example to "clarify" matters,
>because old-style classic classes are *not* unified with types, and
>will disappear in the future:

>
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 a: pass

>>a

<class '__main__.a'>

>>a.__bases__

(<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]

Re: Difference between type and class

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

oj <ojeeves@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]

Re: Difference between type and class

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