else on the same line - howto

[Alex Martelli]

Asun Friere wrote:

> Alex Martelli <aleax at aleax.it> wrote in message
> news:<dHyjb.295947$R32.9705062 at news2.tin.it>...
>> Helmut Jarausch wrote:
>>    ...
>> > So it's a pity that PEP 308 has been rejected since nobody is forced to
>> > use such a construct if he/she doesn't like to.
>> 
>> Anybody programming as a part of a group can be "forced to use a
>> construct" when maintaining others' code that uses it, ...
> 
> That I would have thought, was one of the best arguments _for_ 308.
> Ie, since people want this construct they will write it in all kinds
> of ways, (some unsafe).

...and if and when that happens, you can always remold any obscure
and/or unsafe construct to use, instead, the "one obvious way to
do it" -- if/else WITHOUT any compulsion at all to keep them both
on the same line.  Changing code that's obviously bad to code
that's obviously good is one of the most typical actions during
maintenance.  For example, you notice a snippet:

    if(x > y): return(True)
    else: return(False)

sigh (if that), and turn it into the one obviously right form:

    return x>y

removing the redundant parentheses (violating PEP 8) as well
as collapsing the redundantly baroque structure.  As long as
the language does provide one obvious way to do it, it's a minor
issue that other not-so-obvious ways are almost inevitably
going to be there, too; in practice, you get no objections about
moving from non-obvious to obvious (except from deliberately
bloody-minded people who are only out to annoy, but don't judge
the proportion of such people from traffic on Usenet: they're
much rarer in real life:-).

But if the language "goes out of its way" to take the trouble
to add a specific construct for a task, you're _guaranteed_
that some people in the group will want to use that construct
and in fact will bitterly object to any attempt to remold it
away or negotiate its non-use in coding conventions.  And of
course such construct-lovers have a point: if the language
has adopted the construct, you cannot any more argue that the
construct should always be avoided -- if it's in the language,
there MUST be occasions in which the construct is the best
way to express something (assuming you do accept the language
rather than design a subset of it in coding conventions).

Therefore, it is disingenuous to claim, as Helmut does:

"nobody is forced to use such a construct if he/she doesn't like to."

this is FALSE: everybody who programs in a group is LIKELY to be
forced to use (read, maintain, ...) such a construct whether they
like it or not.

> Against this 308 was proposing that one
> obvious way to do it be adopted -- with obvious benefits for
> maintaining other people's code.  Of course the adoption of a single
> idiom would accomplish this as well.

The obvious single idiom is the if/else statement, and objections
to it come mostly from people who idolize "one-liners" -- see the
subject of this thread again.  Passing PEP 308 would not outlaw
the if/else statement, of course.

We've been through it in the recent past with such innocuous language
additions as += -- suddenly, the obvious-to-anybody code:

    widgets = widgets + 1

was NOT any more "the one obvious way to do it", and the equivalent

    widgets += 1

creeped all over our code.  So be it -- maybe that addition was
worthwhile, and it's far too late to undo it, anyway.  But far from
giving "obvious benefits for maintaining other people's code", such
additions of features give PROBLEMS in this regard.


> Correct me if I'm wrong, but the way I understand it the reason 308
> did not gain favour wasn't on the basis of "I don't wanna use it so
> nobody should have it" (which is an non argument), nor of "When I'm
> maintaining someone else's code I don't want to be confronted with a
> single easily recognised construct" (which is an anti-argument).

Re-read the HUGE threads of the time and try to divine everybody's
reasons for voting the way they did: I'm not any better placed for
reading into others' mind than you are.  But claiming as a
"non argument" the line of reasoning "I don't want to use it, the
ONLY way I'll be able to not use it [in a situation where groups
of people cooperate] is if it's not in the language, so it should
not be in the language" is absurd.  It's a perfectly good argument.

As for recognizing, in other people's code, the goofy and obscure
constructions they will often employ, that's a matter of skill and
experience in software reading and maintenance -- after a while you
get to make good guesses about what programming languages certain
people had previously been exposed to, just from exactly what
malapropisms they're most prone to.  *BUT* if their obscure and
goofy anti-idioms can be shown to be in definite violation of the
language's style and idioms, *YOU GET TO TAKE THEM OUT* and change
them into the simple, readable forms you prefer.  If the language
blesses their usage, YOU'RE STUCK WITH IT in most situations of
practical importance.

> Rather, it was felt that the necessity for this construct was not
> sufficient to justify the 'feature-creep' involved.  Given the
> imperative to keep the language simple, and against the many requests
> for new features, the 'ternary operator' just didn't cut it.

This is no doubt a factor: each new feature needs to fully carry
its weight and then some.  But against this you often hear people
defending a new proposed feature in terms of "and if you don't
like it you don't have to use it", just as is being attempted here:
it's important to understand that this defense is totally fallacious,
and why.  Of course it gets worse exponentially fast with the number
of "don't have to use it" features: if there are ten such features,
then you don't have one language any more, you have a bit more than
a thousand dialects (2 to the 10th power) defined by the subsets of
the too-big language that one IS allowed/encouraged to use in any
given group of programmers.  Avoiding such fragmentation of the
language community is part of why there IS social pressure to use -- in
appropriate ways -- those features that ARE in the language: to keep
us all using the same language rather than 1024 partially overlapping
subsets thereof.  But the root of the problem is with each single
feature that gets added -- and the "don't have to use it" fallacious
and mendacious argument can often lull some people into accepting that
"each single feature", which is why it IS so important to show it
up as BEING mendacious, fallacious, misleading, just plain WRONG.

I could have lived with python-plus-ternary, though I'm a bit happier
with plain good old Python.  But I have less tolerance for this
erroneous and destructive line of reasoning!-)


Alex