wishlist Python3K: subclass ints

[Pete Shinners]

> > 1. Everything is an object of a class that can be subclassed.
> 
> You want to subclass integers, why?

i think this is really important also. i'd like to see all
python objects given the same 'value'

a small sampling of reasons to make all types (yes, even ints)
real class types that can be subclassed

 - "Debug Int" class. want to make an int that prints to
   a log every time it gets assigned? it would be incredibly
   easy if int were its own class. instead now one must
   create a new class and define --ALL-- the different operators
   for an int. what happens when python with the assignment
   modifiers (*=, +=, etc) is released. if int is a class
   your debug Int class works perfectly. with the current
   "unique" int type, you have to go back to your code and
   add the new features (all basic OO arguments apply i guess)
   Along with just "int". How is "int" any less valuable than
   dict or list, which already have their handholding "User..."
   classes

 - (speaking of which) It gets rid of the UserList, UserDict,
   and all its ugly friends. these are the results of a
   flawed design.

 - Just the fact that i could subclass any "C" object would
   make it worth the while.

 - Also gone are all the nit-picking type checking routines.
   instead of first checking if a variable is a "class" type,
   then checking if the object is a certain class, all variables
   hold objects of the same "rank". the best move would be to
   have "int" and "float" be subclassed from a base class like
   "realnumber".

 - Instead of using functions like int(), float(), string()
   why not make int, float, and string a class definition.
   then calling int(10.5) is really calling the constructor
   for the int object.

i'm sure there's a lot more, but in my mind having 
one standard "type" for all python objects would be a big
boost. 

don't get me wrong here. even with all of python's unique
and different object types i think it is still the greatest
language. i just can't think of any good arguments for
py3k to once again segregate objects into different types.