[Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?
solipsis at pitrou.net
Fri Dec 29 09:56:19 EST 2017
On Sat, 30 Dec 2017 00:43:07 +1000
Nick Coghlan <ncoghlan at gmail.com> wrote:
> > That doesn't change my other point that some
> > functions that could previously take non-int arguments can no
> > longer--if we agree on that at least then I can set about making a bug
> > report and fixing it.
> The size_t, ssize_t and void pointer conversions should only accept
> true integers (so either no fallback, or fall back to `__index__`).
> The unsigned long and unsigned long long conversions should likely be
> consistent with their signed counterparts and allow lossy conversions
> via `__int__`.
That is the statu quo indeed... but the destination C type shouldn't
be used as a criterion of which __dunder__ method is called.
For example, let's assume I'm writing a piece of code that expects a
pid number. The C type is `pid_t`, which presumably translates either
to a C `int` or `long` (*). But it's not right to accept a float
I think we really need a bunch a `PyIndex_AsXXX` functions
(`PyIndex_AsLong`, etc.) to complement the current `PyLong_AsXXX`
functions. That way, every `PyLong_AsXXX` function can continue
calling `__int__` (if they ever did so), while `PyIndex_AsXXX` would
only call `__index__`.
(*) I got curious and went through the maze of type definitions on
GNU/Linux. Which gives:
#define __S32_TYPEDEF __signed__ int
#define __PID_T_TYPE __S32_TYPE
__STD_TYPE __PID_T_TYPE __pid_t;
typedef __pid_t pid_t;
More information about the Python-ideas