PEP0238 lament

[Tim Hochberg]

"David Eppstein" <eppstein at ics.uci.edu>:

> Rather than arguing about nonexistent situations,

Uhmm... didn't you ask for an example which I then provided. That hardly
seems like a nonexistent situation.

> let's make an analogy:
> In Python, "123"+"456" = "123456" but 123+456=579.  These are two
different
> operators that happen to have the same symbol.  I really don't see why
> integer-division and floating-point-division should be treated any
> differently from this case.

Because strings aren't numbers and integers are. This has three aspects:
there is a folklore interface (the official term I believe) to the number
class which ints, floats, complexes all satisfy while strings do not. You
can think of the folklore interface as an abstract base class that is so
abstract it doesn't even exist. Second the domain of application of strings
and the number classes is sufficiently disjoint that it's pretty hard for
the overloading of + to mean concatenation in strings to cause problems.
Finally there is automagic coercion between the various number classes which
reinforces their relationship.

The only place that I know of where this is a bit of a pain is for types
that try to be both sequences and numbers (e.g., arrays in NumPy). Even
there this is unlikely to cause an error, one just misses out on some of the
sequence functionality when using arrays since they can't be concatenated or
replicated using infix notation.

> Maybe it would have been more type-safe to have defined a language in
which
> string concatenation was defined by some other symbol ++, so that
> "123"++"456" would equal "123456" but "123"+"456" would automagically
> coerce the arguments into integers and return 579.

I actually would  have preferred a separate concatenation operator (not ++
though for reasons I don't want to get into here). I think the second
suggestion is horrible, again for reasons I don't want to get into here.

> You could argue either
> way on the abstract merits of such a language.  But that's not the
language
> we have now, the automagic coercion violates the "better explicit than
> implicit" principle, and there are too many calls to the
> string-concatenation '+' operator to change them without great pain.

Agreed. And the benifits would be extremely minimal which has to be part of
the equation.

> Another possible step instead of breaking integer division would be to add
> a warning for any int/float or float/int division, to make it more
explicit
> that the two kinds of division are different and that you need to make up
> your mind which one you want to do.  Take out all the automagic and make
> people use explicit casts.

I don't think that's viable. Just issuing warning can break plenty of code.
And tracking down all int/float and float/int cases is sure to be no less
painful than replacing / with // where appropriate.

I can't say whether long term this would be a win for the Python community
as a whole. There obviously potentially painful backwards compatability
issues. All I can say is that for me personally I believe is would be an
improvement. You don't obviously don't think so. That's not a problem.

<RANT>

[Note the you in this rant is not necessarily David, in fact it's mostly not
David, it just so happens that I'm answering his email while being overcome
with the urge to rant.

What is a problem is that most of this thread is nonsense. Of course it
would be better to be able to choose whether you want float or
floor-division. Well duh! And even if you don't agree, you have to be able
to see why others would want that ability. If you can't see that you're
having a complete failure of your imaginative organ.

The issues are obvious: operator proliferation and backward compatibility.
The first is probably minor: is adding another operator, and one that looks
like a comment in several popular languages at that, going to make Python
too disgusting to read? I don't think so, but I can see how someone might
disagree. The second is the biggie: how hard is it fix all the old code.
Particularly how to deal with unmaintained legacy code or code that has to
be maintained for multiple version of Python. Again for me, no problem, but
perhaps not for others.

All the other arguments I've heard come across as aimless thrashing. And as
a result are very unlikely to influence those who you need to convince
(which does not include me in case you hadn't figured that out).

Sigh.

</RANT>

-tim