This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author vstinner
Recipients docs@python, mark.dickinson, vstinner
Date 2010-06-09.10:34:44
SpamBayes Score 0.0007391053
Marked as misclassified No
Message-id <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
In-reply-to
Content
The documentation of PyArg_Parse*() number formats specify that only int / float / complex are accepted, whereas any int / float / complex compatible object is accepted. "compatible" means that it has an __int__() / __float__() / __complex__() method, or nb_int / nb_float of Py_TYPE(obj)->tp_as_number->nb_int is defined (tp_as_number has no nb_complex).

I suppose that the following paragraph is also outdated:

"It is possible to pass "long" integers (integers whose value exceeds the
 platform's :const:`LONG_MAX`) however no proper range checking is done --- the
 most significant bits are silently truncated when the receiving field is too
 small to receive the value (actually, the semantics are inherited from downcasts
 in C --- your mileage may vary)."

Moreover, "without overflow checking" should be explained (Mark told me that the number is truncated to a power of 2).
History
Date User Action Args
2010-06-09 10:34:49vstinnersetrecipients: + vstinner, mark.dickinson, docs@python
2010-06-09 10:34:48vstinnersetmessageid: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za>
2010-06-09 10:34:46vstinnerlinkissue8952 messages
2010-06-09 10:34:44vstinnercreate