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

Logged In: YES 
user_id=6380

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.

Logged In: YES 
user_id=80475

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.

Logged In: YES 
user_id=6380

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

Logged In: YES 
user_id=35752

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

Logged In: YES 
user_id=33168

Is this bug still valid?

Discuss the bug at the bug day.