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. There are differences between the functions int() and trunc() though:

...

...

int("42") 42

...

...

trunc("42") Traceback (most recent call last): File "<stdin>", line 1, in <module> TypeError: type str doesn't define __trunc__ method

Conceptually, I would say that int() is a type conversion, whereas trunc() is an operation on numbers. A type would be entitled to implement them both but differently. -- Greg

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 nearest Integral toward 0." so the option is there for third-party types to return some integral type apart from int. For the stdlib, the only Integral type we have is int. So I think we have the following intended behaviour. * Round a numeric (Real) value to an Integral value: - round to nearest (ties to even): __round__ - round down (towards negative infinity): __floor__ - round up (towards positive infinity): __ceil__ - round towards zero: __trunc__ * Convert a numeric Integral value to an actual int: (intended for indexing of sequences): __index__ * Convert any arbitrary value to an actual int: __int__ Does that seem right? -- Steve

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__

__int__ is for converting to integer, __index__ is for interpreting as integer. The intention of __index__ is that it already has that exact value, whereas __int__ might be rounding. For instance, int(5.25) is 5, but operator.index(5.25) raises. Quoting from that linked page on __index__: "Called ... whenever Python needs to **losslessly** convert the numeric object to an integer object" It is assumed to already be a numeric type (so "5" isn't, even though it could be cast to int), and the conversion should be lossless. I'm not 100% sure, but I think that, if __index__ returns anything, __int__ should return the same thing. There could be edge cases where that's not true though. ChrisA

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__ * https://docs.python.org/dev/reference/datamodel.html#object.__index__

If you want to index a list or array 'a' with index 'i', and i is not an int already, we try to convert it to int using __index__. This should fail for floats, since a[3.14] is a bug. OTOH, int(x) where x is a float should And int(s) where s is a string should also work, so int() can't call __trunc__ (as was explained earlier in the thread).

This seems like a red herring, because str.__int__ is not defined. The code to make int(str) work is a separate code path inside PyNumber_Long(). 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 you'd expect. Regards Antoine.

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 you'd expect.

Maybe an alternate constructor could be added -- such as int.from_number() -- which would be restricted to calling __int__(), __index__(), and __trunc__().

Perhaps. And ideally there would be a corresponding C API. Regards Antoine.

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 proposal would be to remove that special role of `__trunc__` and reduce the `int` constructor to only looking at `__int__` and `__index__`. Obviously that's a backwards incompatible change, but a fairly mild one, with an obvious place to insert a `DeprecationWarning` and a clear transition path for affected code: code that relies on `int` being able to use `__trunc__` would need to add a separate implementation of `__int__`. (We made this change recently for the `Fraction` type in https://bugs.python.org/issue44547.) I opened an issue for this proposal a few weeks back: https://bugs.python.org/issue44977 Mark On Thu, Oct 14, 2021 at 11:50 AM Serhiy Storchaka wrote:

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:

https://mail.python.org/archives/list/python-ideas@python.org/thread/5JKQMIC...

_______________________________________________ Python-Dev mailing list -- python-dev@python.org To unsubscribe send an email to python-dev-leave@python.org https://mail.python.org/mailman3/lists/python-dev.python.org/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/NU3774YD... Code of Conduct: http://python.org/psf/codeofconduct/

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 proposal should include a change to require __int__() in numbers.Real.