In article <[EMAIL PROTECTED]>,
"Martin v. Lowis" <[EMAIL PROTECTED]> wrote:
> > If the ambiguity is that 'int' behaviour is unspecified for floats - is
> > it naive to suggest we specify the behaviour?
>
> The concern is that whatever gets specified is arbitrary. There are many
> ways how an i
""Martin v. Löwis"" <[EMAIL PROTECTED]> wrote in message
news:[EMAIL PROTECTED]
|> If the ambiguity is that 'int' behaviour is unspecified for floats - is
| > it naive to suggest we specify the behaviour?
|
| The concern is that whatever gets specified is arbitrary. There are many
| ways how an i
> If the ambiguity is that 'int' behaviour is unspecified for floats - is
> it naive to suggest we specify the behaviour?
The concern is that whatever gets specified is arbitrary. There are many
ways how an int can be constructed from a float, so why is any such way
better than the others, and de
Raymond Hettinger wrote:
> [Raymond Hettinger]
>
>> Since something similar is happening to math.ceil and math.floor,
>> I'm curious why trunc() ended-up in builtins instead of the math
>> module. Doesn't it make sense to collect similar functions
>> with similar signatures in the same place?
>
