steve at lurking.demon.co.uk
Tue Jul 24 01:05:14 CEST 2001
On 23 Jul 2001 21:51:29 GMT, paul at svensson.org (Paul Svensson) wrote:
>We can solve (2) and (3) by adding _two_ new operators (or functions),
>or we can solve all three by changing x/y to always do (A) or always (B),
>and adding a new operator for the other.
>Andy's proposal for "1//2 = 0.5" solves (2), doing nothing about (1) and (3),
>and I find very little merit in such a half-done (1/3 done) solution.
What is the use of float / float -> int?
That is a very perverse case, and when it is needed it is perfectly
sensible to explicitly specify a round, floor, ciel or whatever
function to ensure you get what you really want.
I'd argue that an operator for this is almost entirely redundant, not
to mention a potential source of errors. It discards precision
silently and without warning - a phrase that has been burned into my
mind forever by the Pro-PEP0238 camp today ;-)
And so, to restate yet again, creating a new '//' operator that
coerces to floats is fine if not to my taste, but the '/' operator
should be left well alone. The only time an integer result from
division is sensible is when the args are integers, so there is no
need to change it. Having one mixed-type operator and one
auto-coercing operator is a tad wierd, but this is not the time to
value pedantic ideals over the professional reputations of Python
advocates. Throwing away your most vocal supporters is not the way to
advance a language.
More information about the Python-list