For review: PEP 308 - If-then-else expression

[Alexander Schmolck]

Erik Max Francis <max at alcyone.com> writes:

> Roy Smith wrote:
> 
> > Or worse, you make the wrong generalization.  If I can write "x = y if
> > y
> > > x else x" then way can't I do the same thing with other statement
> > keywords?  Perhaps I can write "myModule = import foo" as well?
> > No?  Why not?  Why does "if" have a dual role, but not the other
> > keywords?
> 
> I don't know, this argument just doesn't really strike a chord with me
> anywhere.  You could make the same argument about the + operator: 
> Sometimes it means one thing, sometimes it means another.

Yes and it is an annoying design flaw, not just theoretically, but in
practice. Addition and concatenation have about 0 overlap in their semantics
(e.g. transitivity: "1" + "2" != "2" + "1", there is no inverse operation
corresponding to "-" for strings etc.) and I can't think of a any case where
this "polymorphism" would make the slightest sense, i.e. code that
meaningfully adds some types and concatenates others.  

Maybe more importantly, a type might well want to provide both concatenation
and addition. Prime example are Numeric arrays: you can concatenate them, but
not with '+', and because you can use 1D arrays interachangably with lists and
tuples in most circumstances the inappropriate overloading of '+' can
introduce subtle bugs. The indroduction of a distinct operator (like '++' in
haskell or ',' in smalltalk) would have been *much* preferable.

The other, IMO slightly more benign (because less widespread) abuse of
existing operators are rich comparisons.

alex