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 seems that > __int__ has now become a strict equivalent to __trunc__. Of course, > user code can still look up and call the __int__ method explicitly (or > look up the nb_int slot, in C), but that's a bit of anti-pattern. > > Is there a point in having three special methods __index__, __int__ and > __trunc__, if two are them are practically interchangeable?
Today __int__ allows the object be explicitly converted to int. It is defined for example in UUID and IPv4Address. We do not want them to be converted to int implicitly or be valid argument of math.trunc(). __trunc__ adds support of the type in math.trunc(). There is no requirement that it should return an int. GMP numbers can return GMP integers and NumPy arrays can return NumPy arrays (I do not know whether they do). It is similar to __floor__, __ceil__ and __round__. _______________________________________________ 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/ Message archived at https://mail.python.org/archives/list/python-dev@python.org/message/IW4TTWZ2LGZOYUST2CA4X5HXM4XNWA72/ Code of Conduct: http://python.org/psf/codeofconduct/
