Question on Standard Types

[hostmaster]

Hi,

I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid.

There is this part in the book where it says:

"In Python, standard types are not classes, so creating integers and
strings does not involve instantiation".

But later in the book, it talks about 'numeric objects' created when a
numeric literal is assigned to a reference.

So my question now is, if standard types are objects, shouldn't they
have classes as well ? Isn't it that a class is the blueprint of an
object? If they don't have a class to begin with, how are these objects
created?

Thanks.
Al

[John Roth]

"hostmaster " <al***@mylinuxs ite.com> wrote in message
news:ma******** *************** ***********@pyt hon.org...

Hi,

I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid.

There is this part in the book where it says:

"In Python, standard types are not classes, so creating integers and
strings does not involve instantiation".

But later in the book, it talks about 'numeric objects' created when a
numeric literal is assigned to a reference.

So my question now is, if standard types are objects, shouldn't they
have classes as well ? Isn't it that a class is the blueprint of an
object? If they don't have a class to begin with, how are these objects
created?
He's trying to make a fairly subtle point. At least, it's subtle until
you get into the nuts and bolts.

The point is that class instances are a single type, regardless of
the class. So while it's perfectly true to say what he did, it has
very little practical meaning unless you attempt to do an operation
on, say, an integer that depends on something that's unique to
an instance.

John Roth


Thanks.
Al

[Aahz]

In article <ma************ *************** *******@python. org>,
hostmaster <al***@mylinuxs ite.com> wrote:

I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid.

There is this part in the book where it says:

"In Python, standard types are not classes, so creating integers and
strings does not involve instantiation".

Actually, this bit *is* definitely out of date; Python 2.2 introduced
new-style classes, and all the standard types are now new-style classes.
--
Aahz (aa**@pythoncra ft.com) <*> http://www.pythoncraft.com/

This is Python. We don't care much about theory, except where it intersects
with useful practice. --Aahz

[Bengt Richter]

On Sun, 7 Sep 2003 13:18:57 -0400, "John Roth" <ne********@jhr othjr.com> wrote:

"hostmaster " <al***@mylinuxs ite.com> wrote in message
news:ma******* *************** ************@py thon.org...

Hi,

I'm quite new to Python and I am reading this book called 'Core Python
Programming' by Wesley J. Chun. I think that this is not a new book but
I believe some of the points are still valid.

There is this part in the book where it says:

"In Python, standard types are not classes, so creating integers and
strings does not involve instantiation". I think that is out of date.

But later in the book, it talks about 'numeric objects' created when a
numeric literal is assigned to a reference.

So my question now is, if standard types are objects, shouldn't they
have classes as well ? Isn't it that a class is the blueprint of an
object? If they don't have a class to begin with, how are these objects
created?

By "standard types" you mean int and str etc.? Try interactive help for sume suggestive info:

help(int) Help on class int in module __builtin__:

class int(object)
| int(x[, base]) -> integer
|
| Convert a string or number to an integer, if possible. A floating point
| argument will be truncated towards zero (this does not include a string
| representation of a floating point number!) When converting a string, use
| the optional base. It is an error to supply a base when converting a
| non-string. If the argument is outside the integer range a long object
| will be returned instead.
|
| Methods defined here:
|
| __abs__(...)
| x.__abs__() <==> abs(x)
|
| __add__(...)
| x.__add__(y) <==> x+y
|

...
(etc.)
help(str)

Help on class str in module __builtin__:

class str(basestring)
| str(object) -> string
|
| Return a nice string representation of the object.
| If the argument is a string, the return value is the same object.
|
| Method resolution order:
| str
| basestring
| object
|
| Methods defined here:
|
| __add__(...)
| x.__add__(y) <==> x+y

...
(etc.)

He's trying to make a fairly subtle point. At least, it's subtle until
you get into the nuts and bolts.

The point is that class instances are a single type, regardless of You don't mean instances of classes are a single type, I assume. You mean
classes themselves are instances of a single type class, right?
(Except old-style classes, which are of type classobj).
the class. So while it's perfectly true to say what he did, it has I don't know how you are reading it. It seems out of date to me.
very little practical meaning unless you attempt to do an operation
on, say, an integer that depends on something that's unique to
an instance.

You can now subclass int and str etc., which has real and practical meaning though.
And it's a pretty strong indication that int and str are classes of some kind ;-)

Regards,
Bengt Richter

[Martin v. Löwis]

aa**@pythoncraf t.com (Aahz) writes:

"In Python, standard types are not classes, so creating integers and
strings does not involve instantiation".

Actually, this bit *is* definitely out of date; Python 2.2 introduced
new-style classes, and all the standard types are now new-style classes.

The statement was always incorrect. The standard types always involved
instantiation, and integers and strings have always been objects, with
a separate identity. Whether or not they had a relation ship <type
'classobj'> is irrelevant for that.

Regards,
Martin