On 10/15/21, Mark Dickinson wrote:
>
> the proposal would be to remove that special role of `__trunc__` and
> reduce the `int` constructor to only looking at `__int__` and `__index__`.
For Real and Rational numbers, currently the required method to
implement is __trunc__(). ISTM that this
Meta: apologies for failing to trim the context in the previous post.
--
Mark
___
Python-Dev mailing list -- python-dev@python.org
To unsubscribe send an email to python-dev-le...@python.org
https://mail.python.org/mailman3/lists/python-dev.python.org/
I'd propose that we relegate `__trunc__` to the same status as `__floor__`
and `__ceil__`: that is, have `__trunc__` limited to being support for
`math.trunc`, and nothing more. Right now the `int` constructor potentially
looks at all three of `__int__`, `__index__` and `__trunc__`, so the
14.10.21 12:24, Eryk Sun пише:
> Maybe an alternate constructor could be added -- such as
> int.from_number() -- which would be restricted to calling __int__(),
> __index__(), and __trunc__().
See thread "More alternate constructors for builtin type" on Python-ideas:
On Thu, 14 Oct 2021 04:24:30 -0500
Eryk Sun wrote:
>
> > Note that PyNumber_Long() is now the only place inside the interpreter
> > calling the `nb_int` slot. But since it also has those undesirable code
> > paths accepting str and buffer-like objects, it's usable in fewer
> > situations than
On 10/14/21, Antoine Pitrou wrote:
> On Wed, 13 Oct 2021 17:00:49 -0700
> Guido van Rossum wrote:
>>
>> so int() can't call __trunc__ (as was explained earlier in
>> the thread).
I guess this was meant to be "*just* call __trunc__". It's documented
that the int constructor calls the
On Wed, 13 Oct 2021 17:00:49 -0700
Guido van Rossum wrote:
> On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner wrote:
>
> > Honestly, I don't understand well the difference between __int__() and
> > __index__().
> >
> > * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> > *
On Thu, Oct 14, 2021 at 11:52:11AM +1300, Greg Ewing wrote:
> Scratch that, it seems __trunc__ also returns an int, at least
> for floats. Not sure what the logic behind that is.
I'm not sure about the logic either, but it is documented as returning
an Integral:
"Truncates the Real x to the
On Thu, 14 Oct 2021 11:52:11 +1300
Greg Ewing wrote:
> On 14/10/21 11:19 am, Greg Ewing wrote:
> > Not really -- __int__ is expected to return something of type
> > int, whereas __trunc__ is expected to return the same type as
> > its operand.
>
> Scratch that, it seems __trunc__ also returns
On Wed, Oct 13, 2021 at 4:56 PM Victor Stinner wrote:
> Honestly, I don't understand well the difference between __int__() and
> __index__().
>
> * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> * https://docs.python.org/dev/reference/datamodel.html#object.__index__
>
If
On Thu, Oct 14, 2021 at 10:51 AM Victor Stinner wrote:
>
> Honestly, I don't understand well the difference between __int__() and
> __index__().
>
> * https://docs.python.org/dev/reference/datamodel.html#object.__int__
> * https://docs.python.org/dev/reference/datamodel.html#object.__index__
Hi Antoine,
I have a lot of troubles to reminder how Python converts numbers, I
collected notes about the Python "number tower" and the C
implementation:
https://pythondev.readthedocs.io/numbers.html
Honestly, I don't understand well the difference between __int__() and
__index__().
*
On 14/10/21 11:19 am, Greg Ewing wrote:
Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.
Scratch that, it seems __trunc__ also returns an int, at least
for floats. Not sure what the logic behind that is.
On 14/10/21 6:10 am, Antoine Pitrou wrote:
It seems that
__int__ has now become a strict equivalent to __trunc__.
Not really -- __int__ is expected to return something of type
int, whereas __trunc__ is expected to return the same type as
its operand.
--
Greg
13.10.21 20:10, Antoine Pitrou пише:
> It used to be that defining __int__ allowed an object to be accepted as
> an integer from various functions, internal and third-party, thanks to
> being implicitly called by e.g. PyLong_AsLong.
>
> Today, and since bpo-37999, this is no longer the case. It
15 matches
Mail list logo