PEP0238 lament

[Martijn Faassen]

Marcin 'Qrczak' Kowalczyk <qrczak at knm.org.pl> wrote:
> 23 Jul 2001 10:47:08 GMT, Martijn Faassen <m.faassen at vet.uu.nl> pisze:

>> "+" does two different things depending on what you pass in (strings or
>> numbers). "*" does so too. They both can be said to lose information.

> The difference between '+' and '/' is that ints aren't implicitly
> converted to strings, so one wouldn't use an int instead of a string
> expecting '+' to do the conversion and concatenation. But ints *are*
> implicitly converted to floats when needed in about all contexts except
> '/', so it would be reasonable to expect them to be converted in the
> '/' case too.

Huh? Which contexts are that? ints are converted to floats if you use
them together with a float, yes. int + float results in a float answer,
just like int/float does; why do you claim / is an exception in this? 

Anyway, string * int involves in a string result as well, which could
be claimed to be analogous, though I know that's a shaky argument. :)

> In languages where ints are implicitly converted to strings, addition
> and concatenation are typically different operators. Like in Perl:
> '+' and '.'.

And in Perl "1" + "foo" is 1. Hardly ideal as an example of separate
operators. :)
 
> Python does treat ints and floats as different parts of the same
> concept by letting them compare equal and convert as needed. So real
> division and integer division should be distinguished by the operator.

Couldn't you make this argument for float multiplication and integer
multiplication as well though? After all integer * float will lead to
an inexact float result..  Ocaml has separate *. for float multiplication,
for instance.

> To help with migration there can be old_div(x,y) function. That way
> old / can be unconditionally replaced with old_div for a quick fix,
> and it can be made nicer by saying explicitly which division is meant
> when somebody has time to do it properly.

It wouldn't help too much with efficiency, but I imagine that's what people
will end up doing, yes. At least you could make a tool that did that for
each and every / (excluding situations with eval), so that's a relief. It does
raise the question if polluting so much old code with this construct 
(and we can't change code samples) is worth having a slightly easier to
teach language.. 

Regards,

Martijn
-- 
History of the 20th Century: WW1, WW2, WW3?
No, WWW -- Could we be going in the right direction?