[Python-ideas] Is there a reason some of the PyLong_As* functions don't call an object's __int__?

[Antoine Pitrou]

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
there...

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;


Regards

Antoine.