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