[Python-3000] [Python-Dev] Integer representation (Was: ssize_t question: longs in header files)
Guido van Rossum
guido at python.org
Tue May 30 20:16:44 CEST 2006
[Removing python-dev from the CC list]
On 5/29/06, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > That's why I'd like my alternative proposal (int as ABC and two
> > subclasses that may remain anonymous to the Python user); it'll save
> > the alignment waste for short ints and will let us use a smaller int
> > type for the size for long ints (if we care about the latter).
>
> I doubt they can remain anonymous. People often dispatch by type
> (e.g. pickle, xmlrpclib, ...), and need to put the type into a
> dictionary. If the type is anonymous, they will do
>
> dispatch[type(0)] = marshal_int
> dispatch[type(sys.maxint+1)] = marshal_int
>
> Plus, their current code as
>
> dispatch[int] = marshal_int
>
> which will silently break (although it won't be silent if they also
> have dispatch[long] = marshal_long).
Fair enough.
I'm not sure what the downside of exposing "short" and "long" would
be, as long as it remains limited to places where people dispatch on
type(x) -- isinstance(x, int) should always work. And, as /F notes,
hopefully some overloading/dispatching/generic functions machinery
would help.
If we really want all ints to have the same type, a hackish proposal
would be to tweak type() and the __class__ attribute to lie, returning
the 'int' type object when the type or class of a short or long is
requested. This should probably go with a prohibition on subclassing
int to avoid confusion. At the C level, the concrete types would be
exposed.
--
--Guido van Rossum (home page: http://www.python.org/~guido/)
More information about the Python-3000
mailing list