29.12.17 16:43, Nick Coghlan пише:
On 29 December 2017 at 22:58, Erik Bray wrote:
Okay, and it's broken.
Broken in what way? It has a fairly extensive test suite in
https://github.com/python/cpython/blob/master/Lib/test/test_index.py
(and some additional indirect
On 12/29/17 9:56 AM, Antoine Pitrou wrote:
(*) 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.
On Sat, 30 Dec 2017 00:43:07 +1000
Nick Coghlan 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.
On 29 December 2017 at 22:58, Erik Bray wrote:
> On Thu, Dec 28, 2017 at 8:42 PM, Serhiy Storchaka wrote:
>> 28.12.17 12:10, Erik Bray пише:
>>>
>>> There's no index() alternative to int().
>>
>>
>> operator.index()
>
> Okay, and it's broken.
Broken
On Thu, Dec 28, 2017 at 8:42 PM, Serhiy Storchaka wrote:
> 28.12.17 12:10, Erik Bray пише:
>>
>> There's no index() alternative to int().
>
>
> operator.index()
Okay, and it's broken. That doesn't change my other point that some
functions that could previously take non-int
28.12.17 12:10, Erik Bray пише:
There's no index() alternative to int().
operator.index()
___
Python-ideas mailing list
Python-ideas@python.org
https://mail.python.org/mailman/listinfo/python-ideas
Code of Conduct:
On Fri, Dec 8, 2017 at 7:20 PM, Ethan Furman wrote:
> On 12/08/2017 04:33 AM, Erik Bray wrote:
>
>> More importantly not as many objects that coerce to int actually
>> implement __index__. They probably *should* but there seems to be
>> some confusion about how that's to be
On 8 December 2017 at 22:33, Erik Bray wrote:
> In other words, there are probably countless other cases in the stdlib
> at all where it "doesn't make sense" to accept a float, but that
> otherwise should accept objects that can be coerced to int without
> having to
On 12/08/2017 04:33 AM, Erik Bray wrote:
More importantly not as many objects that coerce to int actually
implement __index__. They probably *should* but there seems to be
some confusion about how that's to be used.
__int__ is for coercion (float, fraction, etc)
__index__ is for true
On Fri, 8 Dec 2017 15:12:30 +0100
Erik Bray wrote:
> On Fri, Dec 8, 2017 at 1:52 PM, Antoine Pitrou wrote:
> > On Fri, 8 Dec 2017 14:30:00 +0200
> > Serhiy Storchaka
> > wrote:
> >>
> >> NumPy integers implement __index__.
> >
On Fri, Dec 8, 2017 at 1:52 PM, Antoine Pitrou wrote:
> On Fri, 8 Dec 2017 14:30:00 +0200
> Serhiy Storchaka
> wrote:
>>
>> NumPy integers implement __index__.
>
> That doesn't help if a function calls e.g. PyLong_AsLongAndOverflow().
Right--pointing to
On Fri, 8 Dec 2017 14:30:00 +0200
Serhiy Storchaka
wrote:
>
> NumPy integers implement __index__.
That doesn't help if a function calls e.g. PyLong_AsLongAndOverflow().
Regards
Antoine.
___
Python-ideas mailing list
On Fri, Dec 8, 2017 at 12:26 PM, Serhiy Storchaka wrote:
> 08.12.17 12:41, Erik Bray пише:
>>
>> IIUC, it seems to be carry-over from Python 2's PyLong API, but I
>> don't see an obvious reason for it. In every case there's an explicit
>> PyLong_Check first anyways, so not
08.12.17 13:36, Antoine Pitrou пише:
On Fri, 8 Dec 2017 13:26:48 +0200
Serhiy Storchaka
wrote:
Currently the following functions fall back on __int__ where available:
PyLong_AsLong
PyLong_AsLongAndOverflow
PyLong_AsLongLong
PyLong_AsLongLongAndOverflow
On Fri, 8 Dec 2017 13:26:48 +0200
Serhiy Storchaka
wrote:
>
> > Currently the following functions fall back on __int__ where available:
> >
> > PyLong_AsLong
> > PyLong_AsLongAndOverflow
> > PyLong_AsLongLong
> > PyLong_AsLongLongAndOverflow
> > PyLong_AsUnsignedLongMask
>
08.12.17 12:41, Erik Bray пише:
IIUC, it seems to be carry-over from Python 2's PyLong API, but I
don't see an obvious reason for it. In every case there's an explicit
PyLong_Check first anyways, so not calling __int__ doesn't help for
the common case of exact int objects; adding the fallback
On Fri, 8 Dec 2017 11:41:10 +0100
Erik Bray wrote:
>
> I ran into this because I was passing an object that implements
> __int__ to the maxlen argument to deque(). On Python 2 this used
> PyInt_AsSsize_t which does fall back to calling __int__, whereas
> PyLong_AsSsize_t
IIUC, it seems to be carry-over from Python 2's PyLong API, but I
don't see an obvious reason for it. In every case there's an explicit
PyLong_Check first anyways, so not calling __int__ doesn't help for
the common case of exact int objects; adding the fallback costs
nothing in that case.
I ran
18 matches
Mail list logo