[Python-Dev] Re: PyNumber_Check()

M.-A. Lemburg mal@lemburg.com
Thu, 28 Nov 2002 10:18:58 +0100

[Changing PyNumber_Check() to return True for strings]

Guido van Rossum wrote:
 >> [Example switching on object types where the PyNumber_Check()
 >>  preceeds the PyString_Check()]
>>With the new semantics, the PyNumber_Check() test would
>>succeed for strings, making the second test a no-op.
>>I would expect that this kind of switching on types is
>>not uncommon for code which works in polymorphic ways.
> Alas, I agree with this expectation, even though I believe that such
> code is based on a misunderstanding. :-(
>>>PyNumber_Check() comes from an old era, when the presence or absence
>>>of the as_number "extension" to the type object was thought to be
>>>useful.  If I had to do it over, I wouldn't provide PyNumber_Check()
>>>at all (nor PySequence_Check() nor PyMapping_Check()).
>>Ok, but why not fix those APIs to mean something more
>>useful than deprecating them ? E.g. I would expect that
>>a number is usable as input to float(), int() or long()
>>and that a mapping knows at least about __getitem__.
> Maybe, as long as we all agree that that's *exactly* what they check
> for, and as long as we agree that there may be overlapping areas
> (where two or more of these will return True).
> PyMapping_Check() returns true for a variety of non-mappings like
> strings, lists, and all classic instances.

Perhaps we should simply keep the existing semantics for
those two APIs, that is, ensure that they return the same
results for the standard builtin types as they did in Python 2.2
and below ?!

This would mean that a special case would have to be added
to PyNumber_Check() to have it return False for strings
and Unicode.

Marc-Andre Lemburg
CEO eGenix.com Software GmbH
eGenix.com -- Makers of the Python mx Extensions: mxDateTime,mxODBC,...
Python Consulting:                               http://www.egenix.com/
Python Software:                    http://www.egenix.com/files/python/