[Python-Dev] reflections on basestring -- and other abstractbasetypes

Alex Martelli aleaxit at yahoo.com
Tue Nov 4 05:02:22 EST 2003


On Monday 03 November 2003 07:51 pm, Michael Chermside wrote:
> I (Michael Chermside) wrote:
> > Great idea... I think there should be single type from which all built-in
> > integer-like types inherit, and which user-designed types can inherit
> > if they want to behave like integers. I think that type should be called
> > "int".
>
> Alex replies:
> > Unfortunately, unless int is made an abstract type, that doesn't help at
> > all to "type-flag" user-coded types (be they C-coded or Python-coded):
> > they want to tell "whoever it may concern" that they're intended to be
> > usable as integers, but not uselessly carry around an instance of int for
> > the purpose (and need to contort their own layout, if C-coded, for that).
>
> Valid point. Of course, we've reduced the use cases to those which want
> to emulate integers and ALSO don't want the layout of ints. It seems like
> a small number of situations, but there ARE some, and it IS a valid point.

If some code is happy with extending an existing concrete type there is of
course no problem -- it just goes and do it.  Sorry, I was taking that for
granted.  But, e.g., gmpy.mpz wants to keep "the integer" in the form that
makes the underlying GMP library happy, and any similar wrapper over a
library supplying some special implementations of integers (there are quite
a few besides GMP) would be similar in this way.


> > Abstract basetypes such as basestring are useful only to "flag" types as
> > (intending to conform to) some concept: they don't carry implementation.
>
> Well, yes, but Python strives very hard to not NEED to know what type
> an object is before operating on it. As long as it supports the operations
> that are used, it's "good enough". It's an ideal, not a universal rule,
> and there are pleanty of small exceptions, but to introduce a system
> of basetypes seems inappropriate.

It's a wonderful idea, and I generally crusade against typechecking, but I
think there are enough "small exceptions" that some basestring-like abstract
basetypes may be warranted (not necessarily "a system", mind you).

Typechecking against an abstract type is quite different and less of a
problem than doing so against a concrete type, btw -- exactly because
it's not a big problem for a user-coded type to "flag" itself by inheriting
from the abstract basetype in question, if need be... it doesn't carry the
baggage that inheriting from a concrete type does.


> On the other hand, string and unicode need a common base class because
> they are a special case. Really, there are two things going on... the

They're special to Python itself and its standard library because there
is a lot more string-processing and processing of text going on there
than any other kind.  I.e., the usefulness of basestring is more obvious
because Python itself and the standard library are "keen" users of
strings of all kinds;-).

> both good and bad. But since lots of string objects contain character
> data just like unicode objects, we need a type lable for dealing
> with "character data", and that can't be either "unicode" or "string".
>
> I don't see any such issue in numbers (although the int/long flaw
> is somewhat similar, but that's being healed).

But int/long, and float, have enough similarities AND differences too.
Adding a Decimal or a Rational type (I hope both will eventually occur)
will IMHO show that even more clearly.


> > Surely you're not claiming that
> > Numeric is "abusing operator overloading" by allowing users to code
> > a+b, a*b, a-b etc where a and b are multi-dimensional arrays?  The
> > ability to use such notation, which is fully natural in the application
> > areas those users come from, is important to many users.
>
> Um... no, I didn't mean to claim that. When I wrote it, I was thinking
> "okay, you'd only use these operations (sensibly) on something which
> had an algebra... ie, a number." But that was wrong... matrices have
> an algebra, but they're NOT numbers.

Yes, we totally agree on this.


> I wrote:
> > What use cases do you have for "basenumber" (I don't mean
> > examples of classes that would inherit from basenumber, I mean examples
> > where that inheritance would make a difference)?
>
> Alex responded with actual examples, and I'll have to take the time
> to read them properly before I can respond meaningfully. (But THANKS
> for giving specific examples... it always helps me reason about
> abstract ideas (like "are baseclasses wise for numbers") when I have
> a few concrete examples to check myself against as I go.)

I hope I chose the examples well then...;-)


> Let this be a warning to me... be careful of getting in an argument
> with Alex, since he'll swamp me with far more well-reasoned arguments
> and examples than I have time to _read_, much less respond to. <wink>

<wink> indeed...;-).  


Alex




More information about the Python-Dev mailing list