[Python-Dev] Unifying Long Integers and Integers: baseint (original) (raw)

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