[Python-Dev] Re: PyNumber_Check() (original) (raw)

M.-A. Lemburg mal@lemburg.com
Thu, 28 Nov 2002 10🔞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 PyNumberCheck() 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. :-( PyNumberCheck() comes from an old era, when the presence or absence of the asnumber "extension" to the type object was thought to be useful. If I had to do it over, I wouldn't provide PyNumberCheck() at all (nor PySequenceCheck() nor PyMappingCheck()). 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). PyMappingCheck() 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/