PEP 308: A PEP Writer's Experience - PRO

[Andrew Dalke]

Anders J. Munch:
> To every hard problem, there's a solution that is simple, obvious, and
> wrong.  (Sorry, couldn't resist.)
>
> Your searches are all single-line.  Conditional expressions broken
> over multiple lines are not uncommon.

That's not the point of my post.  Erik Max Francis said:
> I cannot recall every seeing
>
> if (something ? this : that) ...
>
> in either C or C++ code, so I don't see how C/C++ idioms dominating how
> people think about anything is relevant here.  The construct is bad form
> in any language, and I honestly cannot remember ever having seen it.

David Eppstein reponded that he had used it in his code.

Erik Max Francis responded saying:
> In the portion you clipped, I acknowledged that I'm sure that that
> syntax is used _occasionally_, my point was just that it is so rare as
> to be totally irrelevant, especially given that the guy I was pointing
> that out to was someone who favored frequency-based arguments for
> rejecting a conditional operator.

So I specifically talking about Erik Max Francis' assertion that
the construct
  if (something ? this : that)
is "so rare as to be totally irrelevant".  It is not all that rare, as I
showed -- and I chose an analysis which was guaranteed to produce
the minimum number of hits, to set a lower threshold.  I explicitly
ignored cases where more complex forms of ?: were used in the
if condition.

I then followed up on his statement (which I quoted to show that
it wasn't of my origin) that the use of "if(?:)" is "bad form in any
language."

Thus by *his* definition of "bad form" it will be that at least
2-3% of the uses if the if/else expression will be in bad form

> In my personal use, conditional expressions are used a lot in
> debugging diagnostics, which are later deleted.  The frequency of
> conditionals in any codebase snapshot may not reflect the frequency of
> using conditionals.

That's besides the point of this branch of the thread.

> > So again I ask you, what rate of misuse is low enough as to
> > not be a problem?  1%?  10%?  50%?  0.01%?  Apparently
> > it's above 3%.
>
> No examples I have seen so far qualify for the strong term "misuse".
> Bad style perhaps, though I'm not even sure that

Ahh, I consider bad style to be part of misuse.

> >    if (something ? this : that) ...
>
> is bad style.  Can you suggest an alternative?  The only semantically
> neutral rewrite I can think of is
>
>      bool something_var = something;
>      if((something_var && this) || (!something_var && that))

Ummm, as I elsewhere showed there is plenty of C code which
uses

    if (something) {
        this()
    } else {
        that()
   }

even when the ?: alternative could be used.  As such, people do
consider the if/else statement an alternative and even an improvement
to the ?: expression.

> >[...]and I include
> > cases where the if/else expression will be used in lieu of better/
> > more appropriate cases, as in "x = (if obj: obj else: default)"
> > instead of "x = obj or default".
>
>   "x = (if obj: obj else: default)"
>
> is fine.

You consider the if/else expression in this case to be more readable
than the or case?  I don't find that to be so.

>  In all likelyhood whoever wrote this is unfamiliar or
> uncomfortable with "obj or default", and would not have used that
> anyway.  Also, it lends itself to a clarification such as
>
>   "x = (if obj is None: obj else: default)"

People have come to this list (sorry, no references) asking for an if/else
expression to do X, because that's what would be used in <insert language
here>.

When we ask what they need it for, for the most part it's because they
didn't know part of the language, like the "or" solution above.  We
mentioned
it, and that person leaves slightly more enlightened.  For "or" is indeed
the
proper (better/clearer/cleaner) solution.

Were an if/else expression available, it would be used, no questions asked,
and Python's grace made slightly less so.

You say "lends itself to a clarification" but you don't know that in
the code I'm refering to the input can only be of one type and cannot
take a None, so that clarification is unneeded.

To show otherwise you *must* argue from statistics, as otherwise
it's "my gut feelings are better than your gut feelings" and 10,000 posts
later we've gotten nowhere.

                    Andrew
                    dalke at dalkescientific.com