Message107379
| 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:49 | vstinner | set | recipients:
+ vstinner, mark.dickinson, docs@python |
| 2010年06月09日 10:34:48 | vstinner | set | messageid: <1276079688.25.0.118377953399.issue8952@psf.upfronthosting.co.za> |
| 2010年06月09日 10:34:46 | vstinner | link | issue8952 messages |
| 2010年06月09日 10:34:44 | vstinner | create |
|