On Sun, 7 Sep 2003 13:18:57 -0400, "John Roth" <newsgroups@jhrothjr.com> wrote:
[color=blue]
>
>"hostmaster" <alpot@mylinuxsite.com> wrote in message
>news:mailman.1062951612.13844.python-list@python.org...[color=green]
>> 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".[/color][/color]
I think that is out of date.
[color=blue][color=green]
>>
>> 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?[/color][/color]
By "standard types" you mean int and str etc.? Try interactive help for sume suggestive info:
[color=blue][color=green][color=darkred]
>>> help(int)[/color][/color][/color]
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.)
[color=blue][color=green][color=darkred]
>>> help(str)[/color][/color][/color]
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.)
[color=blue]
>
>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[/color]
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).
[color=blue]
>the class. So while it's perfectly true to say what he did, it has[/color]
I don't know how you are reading it. It seems out of date to me.
[color=blue]
>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.[/color]
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
