Question on Standard Types

[Bengt Richter]

On Sun, 7 Sep 2003 13:18:57 -0400, "John Roth" <newsgroups at jhrothjr.com> wrote:

>
>"hostmaster" <alpot at mylinuxsite.com> wrote in message
>news:mailman.1062951612.13844.python-list at python.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