RetroSearch Browse

Thu Jan 24 21:08:09 CET 2008 · https://mail.python.org/pipermail/python-dev/2008-January/076457.html

On Jan 24, 2008 11:36 AM, "Martin v. Löwis" <martin at v.loewis.de> wrote:
> > trunc() has well-defined semantics -- it takes a Real instance and
> > converts it to an Integer instance using round-towards-zero semantics.
>
> No. trunc calls __trunc__, which does whatever it pleases to do.
>
> >>> class A:
> ...   def __trunc__(self):
> ...      return 0
> ...
> >>> a=A()
> >>> trunc(a)
> 0

However, PEP 3141 specifies what it should do for Numbers.

> > int() has undefined semantics -- it takes any object and converts it
> > to an int (a concrete type!) using whatever rules it likes -- the
> > definition of __int__ is up to whatever the source type likes to do.
> > For float this has been defined the same as trunc() above, but for
> > other types, who knows! int() of a string does something completely
> > different.
>
> But why is that a reason to keep trunc()? If you only ever want to
> convert floats to ints, you can use either one, with no difference.
> int() does *not* have undefined semantics, for floats, it converts
> it to an integer using round-towards-zero semantics.

Yes (although it wasn't always specified this way). But I don't like
that, because of the ambiguity of int(x).

-- 
--Guido van Rossum (home page: http://www.python.org/~guido/)

Home - News ( United States | United Kingdom | Italy | Germany ) - Football scores

Showing content from https://mail.python.org/pipermail/python-dev/2008-January/076457.html below:

[Python-Dev] trunc()