[issue8952] Doc/c-api/arg.rst: fix documentation of number formats

New submission from STINNER Victor victor.stinner@haypocalc.com:
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).
---------- assignee: docs@python components: Documentation, Interpreter Core messages: 107379 nosy: docs@python, haypo, mark.dickinson priority: normal severity: normal status: open title: Doc/c-api/arg.rst: fix documentation of number formats versions: Python 3.2
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

Mark Dickinson dickinsm@gmail.com added the comment:
Yes, most of that paragraph is outdated.
We should check exactly what does happen when the "receiving field is too small" (both in practice and in theory). In C, downcasting to an unsigned type is well-defined and will always reduce modulo 2**<width_of_type>. The result of downcasting to a signed type is implementation-defined, however; do we actually do that anywhere? If so, it would be nice to fix it.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

Mark Dickinson dickinsm@gmail.com added the comment:
The other variable of interest here is that some integer formats will accept types with an __index__ method, while others won't. I'm not sure which types fall into each category, right now.
----------
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

STINNER Victor added the comment:
Three years later, nobody looks to be interested to work on this part of the documentation, so I'm closing the issue. => read the code, luke! (not the doc...)
---------- resolution: -> fixed status: open -> closed
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

Georg Brandl added the comment:
It's still a valid bug.
---------- nosy: +georg.brandl resolution: fixed -> status: closed -> open
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

Changes by STINNER Victor victor.stinner@gmail.com:
---------- nosy: -haypo
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________

STINNER Victor added the comment:
This issue is now 5 years old and it doesn't contain much information. It's more a TODO item, and I'm not more interested to work on it. So I close the issue. If you want to work on the doc, please write a patch ;-)
---------- nosy: +haypo resolution: -> out of date status: open -> closed
_______________________________________ Python tracker report@bugs.python.org http://bugs.python.org/issue8952 _______________________________________
participants (3)
-
Georg Brandl
-
Mark Dickinson
-
STINNER Victor