> gvanrossum@projects.sourceforge.net wrote: > > *** NEWS 18 Nov 2002 16:19:39 -0000 1.526 > > --- NEWS 18 Nov 2002 16:27:16 -0000 1.527 > > *************** > > *** 694,698 **** > > - PyNumber_Check() now returns true for string and unicode objects. > > This is a result of these types having a partially defined > > ! tp_as_number slot. > > > > - The string object's layout has changed: the pointer member > > --- 694,700 ---- > > - PyNumber_Check() now returns true for string and unicode objects. > > This is a result of these types having a partially defined > > ! tp_as_number slot. (This is not a feature, but an indication that > > ! PyNumber_check() is not very useful to determine numeric behavior. > > ! It may be deprecated.) > > Perhaps PyNumber_Check() should check that at least > one of nb_int, nb_long, nb_float is available (in addition to the > tp_as_number slot) ?! No, I think PyNumber_Check() should be deprecated. I don't think there's a valid use case for it. If you really want a fuzzy definition like "at least one of nb_int, nb_long, nb_float is available", you can test for that yourself -- IMO that doesn't really make it a number. 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()). --Guido van Rossum (home page: http://www.python.org/~guido/)
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4