Title: Deprecate PyNumber_Check
Type: enhancement Stage:
Components: Interpreter Core Versions: Python 2.6
Status: closed Resolution:
Dependencies: Superseder:
Assigned To: nascheme Nosy List: christian.heimes, gvanrossum, nascheme, nnorwitz, rhettinger
Priority: low Keywords:

Created on 2002-10-25 21:35 by nascheme, last changed 2008-03-20 21:25 by nascheme. This issue is now closed.

Messages (7)
msg12941 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2002-10-25 21:35
I think PyNumber_Check should be deprecated.  An type
having tp_as_number does not mean it is a number.  If we
don't depreciate it, perhaps we should modify the test.
example, we could check for a __int__ method.

Guido, if you decide what to do, assign the bug back to
me and I will work on a patch.
msg12942 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-10-28 02:39
Logged In: YES 

I agree that checking for tp_as_number is bogus. (Ditto for
sequence and mapping -- are these similarly naive?)

Is there any code that currently uses PyNumber_Check? 
Depending on what it is used for, I'd make a different decision.
msg12943 - (view) Author: Raymond Hettinger (rhettinger) * (Python committer) Date: 2002-10-28 13:10
Logged In: YES 

A grep of Modules, Objects, and Python shows that 
PyNumber_Check is only used in selectmodule.c

The sequence and mapping checks are used much more 
frequently but not naively.  They are used as guards before 
the slot is referenced.

msg12944 - (view) Author: Guido van Rossum (gvanrossum) * (Python committer) Date: 2002-10-29 23:02
Logged In: YES 

Adding a test for nb_int *or* nb_float would seem an
adequate redefinition of PyNumber_Check(). But it's still
not perfect -- a class instance *always* passes this test,
for example, and you can get select() to report strange
errors by passing a class instance. (And it also doesn't
help for complex.) The problem is, what to use in the select
module instead of PyNumber_Check()? There really isn't a
decent alternative; we don't want to call PyInt_Check(),
PyLong_Check() and PyFloat_Check() directly, and
PyFloat_AsDouble() reports an unhelpful "bad argument type
for built-in operation" when given a non-number. Hm, maybe
PyFloat_AsDouble() should be changed to report a better error???

I've also noticed that at least some of the calls to
PySequence_Check() seem bogus -- e.g. the ones in
PySequence_List() and in list_fill() (which look like the
same code BTW, as do several others). In fact, I think most
(all?) uses of this should not be there, since they are only
designed to give "nice" error messages, but they are neither
necessary nor sufficient to catch all cases. (They aren't
necessary because all the other PySequence_XXX() APIs do
proper checking anyway.)

I also noticed that PyMapping_Check() again gives a false
sense of security in e.g. posix_execve().
msg12945 - (view) Author: Neil Schemenauer (nascheme) * (Python committer) Date: 2003-02-18 17:50
Logged In: YES 

Progress update:

Guido has changed PyNumber_Check() to check for
nb_int and nb_float.  I improved the PyFloat_AsDouble()
exception message.  Still need to check the usage of
PySequence_Check() and PyMapping_Check().
msg12946 - (view) Author: Neal Norwitz (nnorwitz) * (Python committer) Date: 2005-10-02 00:05
Logged In: YES 

Is this bug still valid?
msg59316 - (view) Author: Christian Heimes (christian.heimes) * (Python committer) Date: 2008-01-05 19:42
Discuss the bug at the bug day.
Date User Action Args
2008-03-20 21:25:56naschemesetstatus: open -> closed
2008-01-05 19:42:12christian.heimessetnosy: + christian.heimes
type: enhancement
messages: + msg59316
versions: + Python 2.6
2002-10-25 21:35:20naschemecreate