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

[Michael Chermside]

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.

> 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.

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
need to process arbitrary collections of bytes, and the need to
process arbitrary collections of characters. The whole thing is thrown
into confusion because "string" is used for storing characters,
particularly when the characters are expected to be ascii. This is for
historical reasons, performance reasons, out of ignorance, because
"string" is easier to type and u"" is more annoying... lots of reasons
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).

> 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.

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.)

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>

-- Michael Chermside