[Python-Dev] Unifying Long Integers and Integers: baseint

Gareth McCaughan gmccaughan at synaptics-uk.com
Thu Aug 12 18:23:33 CEST 2004


[I said:]
>> This is why "integer" is a better name than "baseinteger".
>> For now it can be the common supertype of int and long.
>> In the future, it can be the name of the single integer
>> type.

[Guido:]
> No, that will be int, of course!

Dang. I suppose it has to be, for hysterical raisins.

> Like 'basestring', 'baseinteger' is intentionally cumbersome, because
> it is only the base class of all *built-in* integral types.  Note that
> UserString is *not* subclassing basestring, and likewise if you wrote
> an integer-like class from scratch it should not inherit from
> baseinteger.  Code testing for these types is interested in knowing
> whether something is a member of one of the *built-in* types, which is
> often needed because other built-in operations (e.g. many extension
> modules) only handle the built-in types.
> 
> If you want to test for integer-like or string-like behavior, you
> won't be able to use isinstance(), but instead you'll have to check
> for the presence of certain methods.
> 
> I know this is not easy in the case of integers, but I don't want to
> start requiring inheritance from a marker base type now.  Python is
> built on duck typing.  (Google for it.)

I don't think this is a good reason for rejecting "integer"
as the name of the common supertype of int and long. You'd use
isinstance(x,integer) to check whether x is an integer of
built-in type, just as you currently use isinstance(x,float)
to check whether x is a floating-point number of built-in
type. I see no reason why a cumbersome name is much advantage.

I am, however, convinced by the other argument: All the steps
towards int/long unification that have been taken so far assume
that the endpoint is having a single type called "int", and
that would be derailed by changing the target name to "integer".
Not to mention that there's any amount of code out there that
uses "int" for conversions and the like, which there's no reason
to break.

I can't get away from the feeling that it would, in some possibly
over-abstract sense, have been neater to introduce "integer" as
the supertype and encourage people to *change* from using "int"
(and "long") to using "integer", so that the meanings of "int" and
"long" never change in the unification process. But, even if I
could convince you, it's too late for that :-).

By the way, I wasn't at any point proposing that inheritance
from a "marker" type should be required for anything, and I'm
not sure why you thought I were. I expect I was unclear, and
I'm sorry about that.

-- 
g



More information about the Python-Dev mailing list