[Python-Dev] basenumber redux

["Martin v. Löwis"]

Alex Martelli wrote:
> I can't find a PEP describing this restriction of basestring, and I  
> don't see why a coder who needs to implement another kind of  
> character string shouldn't subclass basestring, so that those  
> instances pass an isinstance test on basestring which is quite likely  
> to be found e.g. in the standard library.

People could do that, but they would be on their own. basestring
could be interpreted as "immutable sequence of characterish things",
but it was really meant to be "union of str and unicode". There
is no PEP because it was introduced by BDFL pronouncement.

That it is not a generic base class for stringish types can be
seen by looking at UserString.UserString, which doesn't inherit
from basestring.

For most practical purposes, those two definitions actually
define the same thing - there simply aren't any stringish data
types in praxis: you always have Unicode, and if you don't,
you have bytes.

> Implementing different kinds of numbers is more likely than  
> implementing different kinds of strings, of course.

Right. That's why a PEP is needed here, but not for basestring.

> A third argument against it is asymmetry: why should I use completely  
> different approaches to check if x is "some kind of string", vs  
> checking if x is "some kind of number"?

I guess that's for practicality which beats purity. People often
support interfaces that either accept both an individual string
and a list of strings, and they need the test in that case.
It would be most natural to look for whether it is a sequence;
unfortunately, strings are also sequences.

> isinstance with a tuple of number types, where the tuple did not  
> include Decimal (because when I developed and tested that module,  
> Decimal wasn't around yet).

As I suggested in a different message: Why are you doing that
in the first place?

> I have the same issue in the C-coded extension gmpy: I want (e.g.) a  
> gmpy.mpq to be able to be constructed by passing any number as the  
> argument, but I have no good way to say "what's a number", so I use  
> rather dirty tricks -- in particular, I've had to tweak things in a  
> weird direction in the latest gmpy to accomodate Python 2.4  
> (specifically Decimal).

Not sure what a gmpy.mpq is, but I would expect that can only work
if the  parameter belongs to some algebraic ring homomorphic
with the real numbers, or some such. Are complex numbers also numbers?
Is it meaningful to construct gmpy.mpqs out of them? What about
Z/nZ?

> If I do write the PEP, should it be just about basenumber, or should  
> it include baseinteger as well?

I think it should only do the case you care about. If others have other
use cases, they might get integrated, or they might have to write
another PEP.

Regards,
Martin