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 21  5134 
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'.
So int is a type, but if you have an int variable, its type is int.
Same for your classes.
This is, ignoring old style classes. Make sure all your classes
inherit from object to get new style classes.
Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
`Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of signatures,
whereas a class tells us how an object is implemented (like a
blueprint). A class can have many types if it implements all their
interfaces, and different classes can have the same type if they share a
common interface. The following example should clarify matters:
class A:
def bar(self):
print "A"
class B:
def bar(self):
print "B"
class C:
def bla(self):
print "C"
def foo(x):
x.bar()
you can call foo with instances of both A and B, because both classes
share a common type, namely the type that has a `bar' method), but not
with an instance of C because it has no method `bar'. Btw, this example
shows the use of duck typing ( http://en.wikipedia.org/wiki/Duck_typing).
HTH,
Thomas.
Thomas Troeger <th****************@siemens.comwrites:
>Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of
signatures, whereas a class tells us how an object is implemented
(like a blueprint). A class can have many types if it implements all
their interfaces, and different classes can have the same type if they
share a common interface. The following example should clarify
matters:
class A:
def bar(self):
print "A"
class B:
def bar(self):
print "B"
class C:
def bla(self):
print "C"
def foo(x):
x.bar()
you can call foo with instances of both A and B, because both classes
share a common type, namely the type that has a `bar' method), but not
with an instance of C because it has no method `bar'. Btw, this
example shows the use of duck typing
(http://en.wikipedia.org/wiki/Duck_typing).
That would imply that I cannot create instances of a type, only of
a class that implements the type, wouldn't it?
But Python denotes 'int' as a type *and* I can instantiate it.
Still confused,
-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
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(object):
.... pass
....
>>int_class
<class '__main__.int_class'>
>>int
<type 'int'>
why doesn't this print
>>class int_class(object):
.... pass
....
>>int_class
<type '__main__.int_class'>
>>int
<type 'int'>
or
>>class int_class(object):
.... pass
....
>>int_class
<class '__main__.int_class'>
>>int
<class 'int'>
If there is no distinction, how does the Python interpreter know when
to print 'class' and when to print 'type'?
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
Le Thursday 31 July 2008 14:30:19 Nikolaus Rath, vous avez écritÂ*:
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(object):
... pass
...
>int_class
<class '__main__.int_class'>
>int
<type 'int'>
why doesn't this print
>class int_class(object):
... pass
...
>int_class
<type '__main__.int_class'>
>int
<type 'int'>
or
>class int_class(object):
... pass
...
>int_class
<class '__main__.int_class'>
>int
<class 'int'>
If there is no distinction, how does the Python interpreter know when
to print 'class' and when to print 'type'?
There are some confusion about the terms here.
Classes are instances of type 'type', but types are both instances and
subclasses of 'type'.
This recursivity is the base of the object model.
An instance of 'type' is a class (or a new type), but instances of a classes
are not. 'type' is a metatype in term of OO.
What the <type intmeans is that int is not a user type but a builtin type,
instances of int are not types (or classes) but common objects, so its nature
is the same as any classes.
The way it prints doesn't matter, it's just the __repr__ of any instance, and
the default behavior for instances of type is to return '<class XX>', but it
can be easily customized.
>>>[1]: class A(object) :
...: class __metaclass__(type) :
...: def __repr__(self) : return "<type A>"
...:
...:
>>>[2]: A
...[2]: <type A>
>>>[3]: type('toto', (object,), {})
...[3]: <class '__main__.toto'>
--
_____________
Maric Michaud
That would imply that I cannot create instances of a type, only of
a class that implements the type, wouldn't it?
But Python denotes 'int' as a type *and* I can instantiate it.
Now I start getting confused also ;-)
>>a=5
a.__class__
<type 'int'>
>>a.__class__.__class__
<type 'type'>
>>dir(a)
['__abs__', '__add__', '__and__', '__class__', '__cmp__', '__coerce__',
'__delattr__', '__div__', '__divmod__', '__doc__', '__float__',
'__floordiv__', '__getattribute__', '__getnewargs__', '__hash__',
'__hex__', '__index__', '__init__', '__int__', '__invert__', '__long__',
'__lshift__', '__mod__', '__mul__', '__neg__', '__new__', '__nonzero__',
'__oct__', '__or__', '__pos__', '__pow__', '__radd__', '__rand__',
'__rdiv__', '__rdivmod__', '__reduce__', '__reduce_ex__', '__repr__',
'__rfloordiv__', '__rlshift__', '__rmod__', '__rmul__', '__ror__',
'__rpow__', '__rrshift__', '__rshift__', '__rsub__', '__rtruediv__',
'__rxor__', '__setattr__', '__str__', '__sub__', '__truediv__', '__xor__']
I think in Python everything is implemented as a class which makes
sense. AFAIK you can implement a certain interface in a custom class and
it behaves like, for example, a builtin integer. But I guess one of the
gurus can clarify this matter with an appropriate URL ;-)
Maric Michaud <ma***@aristote.infowrites:
Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
`Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of signatures,
whereas a class tells us how an object is implemented (like a
blueprint). A class can have many types if it implements all their
interfaces, and different classes can have the same type if they share a
common interface. The following example should clarify matters:
Of course, this is what a type means in certain literature about OO
(java-ish), but this absolutely not what type means in Python. Types
are a family of object with a certain status, and they're type is
"type", conventionnaly named a metatype in standard OO.
[...]
Hmm. Now you have said a lot about Python objects and their type, but
you still haven't said what a type actually is (in Python) and in what
way it is different from a class. Or did I miss something?
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
Maric Michaud <ma***@aristote.infowrites:
Le Thursday 31 July 2008 14:30:19 Nikolaus Rath, vous avez écritÂ*:
>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(object):
... pass
...
>>int_class
<class '__main__.int_class'>
>>int
<type 'int'>
why doesn't this print
>>class int_class(object):
... pass
...
>>int_class
<type '__main__.int_class'>
>>int
<type 'int'>
or
>>class int_class(object):
... pass
...
>>int_class
<class '__main__.int_class'>
>>int
<class 'int'>
If there is no distinction, how does the Python interpreter know when
to print 'class' and when to print 'type'?
There are some confusion about the terms here.
Classes are instances of type 'type',
Could you please clarify what you mean with 'instance of type X'? I
guess you mean that 'y is an instance of type X' iif y is constructed
by instantiating X. Is that correct?
What the <type intmeans is that int is not a user type but a
builtin type, instances of int are not types (or classes) but common
objects, so its nature is the same as any classes.
The way it prints doesn't matter, it's just the __repr__ of any instance, and
the default behavior for instances of type is to return '<class XX>', but it
can be easily customized.
But 'int' is an instance of 'type' (the metaclass):
>>int.__class__
<type 'type'>
so it should also return '<class int>' if that's the default behavior
of the 'type' metaclass.
I think that to get '<type int>' one would have to define a new
metaclass like this:
def type_meta(type):
def __repr__(self)
return "<type %s>" % self.__name__
and then one should have int.__class__ == type_meta. But obviously
that's not the case. Why?
Moreover:
>>class myint(int):
.... pass
....
>>myint.__class__ == int.__class__
True
>>int
<type 'int'>
>>myint
<class '__main__.myint'>
despite int and myint having the same metaclass. So if the
representation is really defined in the 'type' metaclass, then
type.__repr__ has to make some kind of distinction between int and
myint, so they cannot be on absolute equal footing.
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
Le Thursday 31 July 2008 16:46:28 Nikolaus Rath, vous avez écritÂ*:
Maric Michaud <ma***@aristote.infowrites:
Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
`Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of signatures,
whereas a class tells us how an object is implemented (like a
blueprint). A class can have many types if it implements all their
interfaces, and different classes can have the same type if they sharea
common interface. The following example should clarify matters:
Of course, this is what a type means in certain literature about OO
(java-ish), but this absolutely not what type means in Python. Types
are a family of object with a certain status, and they're type is
"type", conventionnaly named a metatype in standard OO.
[...]
Hmm. Now you have said a lot about Python objects and their type, but
you still haven't said what a type actually is (in Python) and in what
way it is different from a class. Or did I miss something?
This paragraph ?
"""
- types, or classes, are all instance of type 'type' (or a subclass of it),
they can be instantiated and they produce objects (ordinary object in
general) with theirslef as a type.
"""
Maybe it's still unclear that "types" and "classes" *are* synonyms in Python.
--
_____________
Maric Michaud
Maric Michaud <ma***@aristote.infowrites:
Le Thursday 31 July 2008 16:46:28 Nikolaus Rath, vous avez écritÂ*:
>Maric Michaud <ma***@aristote.infowrites:
Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
`Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of signatures,
whereas a class tells us how an object is implemented (like a
blueprint). A class can have many types if it implements all their
interfaces, and different classes can have the same type if they share a
common interface. The following example should clarify matters:
Of course, this is what a type means in certain literature about OO
(java-ish), but this absolutely not what type means in Python. Types
are a family of object with a certain status, and they're type is
"type", conventionnaly named a metatype in standard OO.
[...]
Hmm. Now you have said a lot about Python objects and their type, but
you still haven't said what a type actually is (in Python) and in what
way it is different from a class. Or did I miss something?
This paragraph ?
"""
- types, or classes, are all instance of type 'type' (or a subclass of it),
Well, I couldn't quite make sense of '..are instance of type...'
without knowing what you actually meant with "type* in this context,
but...
Maybe it's still unclear that "types" and "classes" *are* synonyms
in Python.
...in this case it becomes clear. Then my question reduces to the one
in the other post (why do 'int' and 'myint' have different __repr__
results).
Already thanks for your help,
-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
Le Thursday 31 July 2008 17:00:51 Nikolaus Rath, vous avez écritÂ*:
There are some confusion about the terms here.
Classes are instances of type 'type',
Could you please clarify what you mean with 'instance of type X'? I
guess you mean that 'y is an instance of type X' iif y is constructed
by instantiating X. Is that correct?
Correct, you can verify this with the isinstance builtin :
>>>[1]: isinstance(int(), int)
...[1]: True
>>>[2]: isinstance(int, object)
...[2]: True
>>>[3]: isinstance(int, type)
...[3]: True
>>>[4]: class A(object) : pass
...:
>>>[5]: isinstance(A, type)
...[5]: True
What the <type intmeans is that int is not a user type but a
builtin type, instances of int are not types (or classes) but common
objects, so its nature is the same as any classes.
The way it prints doesn't matter, it's just the __repr__ of any instance,
and the default behavior for instances of type is to return '<class XX>',
but it can be easily customized.
But 'int' is an instance of 'type' (the metaclass):
>int.__class__
<type 'type'>
so it should also return '<class int>' if that's the default behavior
of the 'type' metaclass.
The fact that a class is an instance of type, which it is always true, doesn't
mean its metaclass is "type", it could be any subclass of type :
>>>[6]: class A(object) :
...: class __metaclass__(type) :
...: def __repr__(self) : return "<type A>"
...:
...:
>>>[7]: isinstance(A, type)
...[7]: True
>>>[8]: A.__class__
...[8]: <class '__main__.__metaclass__'>
>>>[9]: issubclass(A.__class__, type)
...[9]: True
I think that to get '<type int>' one would have to define a new
metaclass like this:
def type_meta(type):
Â* Â* def __repr__(self)
Â* Â* Â* Â* Â*return "<type %s>" % self.__name__
and then one should have int.__class__ == type_meta. But obviously
that's not the case. Why?
Moreover:
>class myint(int):
... Â* Â*pass
...
>myint.__class__ == int.__class__
True
*is* comparaison fits better here.
>int
<type 'int'>
>myint
<class '__main__.myint'>
despite int and myint having the same metaclass. So if the
representation is really defined in the 'type' metaclass, then
type.__repr__ has to make some kind of distinction between int and
myint, so they cannot be on absolute equal footing.
You're right, type(int) is type, the way it renders differently is a detailof
its implementation, you can do things with builtin types (written in C) you
coudn't do in pure python, exactly as you couldn't write recursive types
like 'object' and 'type'.
--
_____________
Maric Michaud
Maric Michaud <ma***@aristote.infowrites:
>>What the <type intmeans is that int is not a user type but a
builtin type, instances of int are not types (or classes) but common
objects, so its nature is the same as any classes.
The way it prints doesn't matter, it's just the __repr__ of any instance,
and the default behavior for instances of type is to return '<class XX>',
but it can be easily customized.
But 'int' is an instance of 'type' (the metaclass):
>>int.__class__
<type 'type'>
so it should also return '<class int>' if that's the default behavior
of the 'type' metaclass.
The fact that a class is an instance of type, which it is always true, doesn't
mean its metaclass is "type", it could be any subclass of type :
Yes, that is true. But it's not what I said above (and below).
'obj.__class__' gives the class of 'obj', so if 'int.__class__ is
type' then 'type' is the class of 'int' and 'int' is *not* an instance
of some metaclass derived from 'type'.
>I think that to get '<type int>' one would have to define a new
metaclass like this:
def type_meta(type):
Â* Â* def __repr__(self)
Â* Â* Â* Â* Â*return "<type %s>" % self.__name__
and then one should have int.__class__ is type_meta. But obviously
that's not the case. Why?
Moreover:
>>class myint(int):
... Â* Â*pass
...
>>myint.__class__ is int.__class__
True
>>int
<type 'int'>
>>myint
<class '__main__.myint'>
despite int and myint having the same metaclass. So if the
representation is really defined in the 'type' metaclass, then
type.__repr__ has to make some kind of distinction between int and
myint, so they cannot be on absolute equal footing.
You're right, type(int) is type, the way it renders differently is a
detail of its implementation, you can do things with builtin types
(written in C) you coudn't do in pure python, exactly as you
couldn't write recursive types like 'object' and 'type'.
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?
And where exactly is this different rendering implemented? Could I
write my own type (in C, of course) and make it behave like e.g.
'int'? I.e. its rendering should be different and not inherited to
subclasses:
>>my_type
<strange_thing 'my_type'>
>>a = my_type(42)
a.__class__
<strange_thing 'my_type'>
>>class derived(my_type):
pass
<class 'derived>
or would I have to change the implemention of 'type' for this (since
it contains the __repr__ function that renders the type)?
This is of course purely theoretical and probably without any
practical relevance. I'm if I just can't stop drilling, but I think
this is really interesting.
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
On Thu, 31 Jul 2008 13:32:39 +0200, Thomas Troeger wrote:
>Can someone explain to me the difference between a type and a class?
If your confusion is of a more general nature I suggest reading the
introduction of `Design Patterns' (ISBN-10: 0201633612), under
`Specifying Object Interfaces'.
In short: A type denotes a certain interface, i.e. a set of signatures,
whereas a class tells us how an object is implemented (like a
blueprint). A class can have many types if it implements all their
interfaces, and different classes can have the same type if they share a
common interface.
I fear you're introducing a rather complicated answer for a simple
question. In Python, the simple answer is that built-in objects like int,
float, str etc. are referred to as "types", and custom objects created
using the class keyword are referred to as "classes". This is a
historical distinction that will disappear in time.
We can see that types and classes already have the same type in Python:
>>class Parrot(object):
.... pass
....
>>type(Parrot)
<type 'type'>
>>type(str)
<type 'type'>
The following example should clarify matters:
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:
>>class Old: # don't inherit from object
.... pass
....
>>type(Old)
<type 'classobj'>
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).
--
Steven
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:
>>class myint(int): pass
....
>>int
<class 'int'>
>>myint
<class '__main__.myint'>
The reason the distinction is made currently is that before Python
2.2, "types" were built-in (or C extension) classes, and "classes"
were Python classes; it was not possible to subclass built-in types.
That "classic" style of classes are still supported in Python 2.2 and
above (but not in Python 3), by not inheriting from object or any
other built-in. However, for new-style classes, the only distinction
is in the repr.
>>class classic: pass
....
>>class newstyle(object): pass
....
>>type(classic)
<type 'classobj'>
>>type(classic())
<type 'instance'>
>>classic.__class__
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
AttributeError: class classic has no attribute '__class__'
>>classic().__class__
<class __main__.classic at 0x64e70>
>>>
type(newstyle)
<type 'type'>
>>type(newstyle())
<class '__main__.newstyle'>
Further reading: http://www.python.org/download/relea....3/descrintro/ http://svn.python.org/view?rev=23331&view=rev http://bugs.python.org/issue2565
-Miles
Miles <se*********@gmail.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
Steven D'Aprano <st***@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
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.
Thomas Troeger <th****************@siemens.comwrote:
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-
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.
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(object):
... pass
...
>>>int_class
<class '__main__.int_class'>
>>>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
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.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 This thread has been closed and replies have been disabled. Please start a new discussion. Similar topics
by: roopa |
last post by:
I have declared a class with name List;
and in main() function, i have declared the List object as follows
class List
{
public:
List()
{
cout<<"In List Constuctor";
|
by: Shea Martin |
last post by:
I have been programming in C++ for over 4 years. I *think* I knew that
a struct could have a constructor but I decided to dig into it a little
more today, and found that there is very little...
|
by: yufufi |
last post by:
lets say we have a 'shape' class which doesn't implement IComparable
interface..
compiler doesn't give you error for the lines below..
shape b= new shape();
IComparable h;
h=(IComparable)b;...
|
by: ad |
last post by:
I am confuse about type and class in some book about C#.
What is the difference between type and class?
|
by: JonathanOrlev |
last post by:
Hello everyone,
I have a newbe question:
In Access (2003) VBA, what is the difference between a Module and a
Class Module in the VBA development environment?
If I remember correctly, new...
|
by: André |
last post by:
Hi,
i'm learning working with classes.
In class "classbase1", i defined an overridable function. In the class
"subclass1", i defined the same function with 'Overrides'.
In class "classbase2", i...
|
by: fcvcnet |
last post by:
Hi,
I read the book C++ Primer, Fourth Edition By Stanley B. Lippman,
Jos¨¦e Lajoie, Barbara E. Moo
"If we define a class using the class keyword, then any members
defined before the first...
|
by: Jess |
last post by:
Hello,
I understand the default-initialization happens if we don't initialize
an object explicitly. I think for an object of a class type, the
value is determined by the constructor, and for...
|
by: mthread |
last post by:
Hi,
I am learning C++ and I have been told that an object can be
created either by using calloc or new. If it is true, can some one
tell me what is the difference b/w using these two function...
|
by: Charles Arthur |
last post by:
How do i turn on java script on a villaon, callus and itel keypad mobile phone
|
by: ryjfgjl |
last post by:
In our work, we often receive Excel tables with data in the same format. If we want to analyze these data, it can be difficult to analyze them because the data is spread across multiple Excel files...
|
by: BarryA |
last post by:
What are the essential steps and strategies outlined in the Data Structures and Algorithms (DSA) roadmap for aspiring data scientists? How can individuals effectively utilize this roadmap to progress...
|
by: nemocccc |
last post by:
hello, everyone, I want to develop a software for my android phone for daily needs, any suggestions?
|
by: Hystou |
last post by:
There are some requirements for setting up RAID:
1. The motherboard and BIOS support RAID configuration.
2. The motherboard has 2 or more available SATA protocol SSD/HDD slots (including MSATA, M.2...
|
by: Hystou |
last post by:
Most computers default to English, but sometimes we require a different language, especially when relocating. Forgot to request a specific language before your computer shipped? No problem! You can...
|
by: Oralloy |
last post by:
Hello folks,
I am unable to find appropriate documentation on the type promotion of bit-fields when using the generalised comparison operator "<=>".
The problem is that using the GNU compilers,...
|
by: jinu1996 |
last post by:
In today's digital age, having a compelling online presence is paramount for businesses aiming to thrive in a competitive landscape. At the heart of this digital strategy lies an intricately woven...
|
by: Hystou |
last post by:
Overview:
Windows 11 and 10 have less user interface control over operating system update behaviour than previous versions of Windows. In Windows 11 and 10, there is no way to turn off the Windows...
| |
