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 manually wrap those objects wit
If by no brainer you mean the performance of __sort-key__ is always better
of __lt__
No. By no-brainer I meant that IF there is a __sort_key__ defined, then it
should be used for sorting, regardless of whether __lt__ is also defined.
(min and max should probably prefer __lt__)
I will wask for a
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 integer
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__.
> >
> > That doesn't help if a function calls e.g. PyLong_AsLongAndOv
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 __index__ basically implies that PyIndex_C
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
Python-ideas@python.org
https://
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 calling __int__ doesn't
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
PyLong_AsUnsignedLongMask
PyLong_AsUnsi
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
> > PyLong_AsUnsignedLon
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 co
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 does not.
It should pro
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 i
12 matches
Mail list logo
