On Tue, 26 Feb 2008 21:41:16 -0800, Paul Rubin wrote:
> Mark Dickinson <[EMAIL PROTECTED]> writes:
>> > So use: return sum(number_list) / float(len(number_list)) That makes
>> > it somewhat more explicit what you want. Otherwise
>>
>> But that fails for a list of Decimals...
>
> Again, that depends on what your application considers to be failure.
> Heck, int/int = float instead of decimal might be a failure.
>
> FWIW, I just checked Haskell: int/int is not allowed (compile time type
> error). There is an integer division function `div`, like Python's //,
> . that you can use if you want an integer quotient. If you want a
> floating or rational quotient, you have to coerce the operands manually.
> Explicit is better than implicit.
Argument by platitude now? I can play that game too. You forget that
practicality beats purity.
When it comes to mixed arithmetic, it's just too darn inconvenient to
forbid automatic conversions. Otherwise you end up either forbidding
things like 1 + 1.0 on the basis that it isn't clear whether the
programmer wants an int result or a float result, or else even more
complex rules ("if the left operator is an int, and the result of the
addition has a zero floating-point part, then the result is an int,
otherwise it's an error, but if the left operator is a float, the result
is always a float"). Or a proliferation of operators, with integer and
floating point versions of everything.
--
Steven
--
http://mail.python.org/mailman/listinfo/python-list
