Inline Conditionals?

J

Joshua Ginsberg

Is there any plan to include inline conditionals in Python? For example:

def isNegative(x):
return x < 0 ? True : False

Thanks!

-jag
 
A

Adonis

Joshua Ginsberg said:
Is there any plan to include inline conditionals in Python? For example:

def isNegative(x):
return x < 0 ? True : False

Thanks!

-jag

How about something like:
.... if condition:
.... return true
.... return false
....
Hope this helps.

Adonis
 
C

Chris Dutton

Adonis said:
How about something like:



... if condition:
... return true
... return false
...

Just a thought, but this would have unexpected results if used with
function calls, if those function calls had side-effects, since both are
evaluated, whereas the ternary operator in other languages only
evaluates one of the possible expressions.
 
M

Michael Hudson

Joshua Ginsberg said:
Is there any plan to include inline conditionals in Python? For example:

def isNegative(x):
return x < 0 ? True : False

Read PEP 308, and note that this was probably the largest flamewar in
Python history (well, before the still-ongoing decorators
discussion...).

But to answer your question: no.

Cheers,
mwh
 
A

Alex Martelli

Peter Hansen said:
This is a FAQ:

Newbies, please consider reading the several FAQs that you will find
at http://www.python.org/doc/faq/ before posting questions which
might be answered there (i.e. just about anything).

Peter's right. And Joshua's example shows how wise the BDFL was in
ruling out ternaries: sure, good programmers might occasionally have
found good uses for them, but we' have paid that with a LOT of horrid
code like that -- I've seen lots like that in C & its ilk, too.

return x < 0

on its own does EXACTLY the same job as the requested/wished-for

return x < 0 ? True : False

except is cleaner, clearer, faster, more concise, easier to read. So,
having a ternary operator would enable a little programming horror that
the lack of a ternary operator dissuades a little.

Of course, absit iniuria verbis, one cannot make anything foolproof,
because fools are SO ingenious -- I've also seen lots of code like:

if x < 0:
return True
else:
return False

which is, si licet es, even _worse_ than the wished-for ternary use!-)


Alex
 
A

Antoon Pardon

Op 2004-08-26 said:
Peter's right. And Joshua's example shows how wise the BDFL was in
ruling out ternaries: sure, good programmers might occasionally have
found good uses for them, but we' have paid that with a LOT of horrid
code like that -- I've seen lots like that in C & its ilk, too.

When using list comprehension not having a ternary operator can be
a PITA. It is of course possible I miss something but how am I
supposed to do the following:

[ x.property ? foo(x) : bar(x) for x in Somelist ]
 
J

JCM

Antoon Pardon said:
Op 2004-08-26, Alex Martelli schreef <[email protected]>: ....
When using list comprehension not having a ternary operator can be
a PITA. It is of course possible I miss something but how am I
supposed to do the following:
[ x.property ? foo(x) : bar(x) for x in Somelist ]

def foo_or_bar(x):
if x.property:
return foo(x)
return bar(x)

[foo_or_bar(x) for x in Somelist]


(still, I'd like to see a ternary conditional operator too...)
 
J

John J. Lee

Of course, absit iniuria verbis, one cannot make anything foolproof,
because fools are SO ingenious -- I've also seen lots of code like:

if x < 0:
return True
else:
return False

which is, si licet es, even _worse_ than the wished-for ternary use!-)
[...]

Argh.

I looked at that, and had a sinking feeling. I just found about ten
instances of that in my code!

Strange that, though I was innoculated against the general case of
this disease in the some years ago, I was apparently still entirely
susceptible to this particular strain of it.


John
 
A

Alex Martelli

Antoon Pardon said:
When using list comprehension not having a ternary operator can be
a PITA. It is of course possible I miss something but how am I
supposed to do the following:

[ x.property ? foo(x) : bar(x) for x in Somelist ]

If you HAVE to use an LC by doctor's order, the above effect might be
obtained by coding something like:

[ (bar,foo)[bool(x.property)](x) for x in Somelist ]

If your physician should relent and let you code normal Python, though,

aux = []
for x in Somelist:
if x.property:
aux.append(foo(x))
else
aux.append(foo(x))

would be vastly more readable; "sparse is better than dense" and any LC
is far too dense to be Pythonic here.


Alex
 
P

Paul Rubin

aux = []
for x in Somelist:
if x.property:
aux.append(foo(x))
else
aux.append(foo(x))

would be vastly more readable; "sparse is better than dense" and any LC
is far too dense to be Pythonic here.

Hmm,

[ x.property ? foo(x) : bar(x) for x in Somelist ]

doesn't seem too dense, unless you consider -every- LC to be too
dense, in which case why have them? The LC seems to me to be both
more readable and harder to get wrong, unlike your sparse example,
which has 'foo' on both branches of the conditional where you meant
'foo' and 'bar'.

I could see adding some parentheses in the LC to improve readability:

[ (x.property ? foo(x) : bar(x)) for x in Somelist ]

but it doesn't seem like a big deal.
 
A

Alex Martelli

Paul Rubin said:
aux = []
for x in Somelist:
if x.property:
aux.append(foo(x))
else
aux.append(foo(x))

would be vastly more readable; "sparse is better than dense" and any LC
is far too dense to be Pythonic here.

Hmm,

[ x.property ? foo(x) : bar(x) for x in Somelist ]

doesn't seem too dense, unless you consider -every- LC to be too
dense, in which case why have them?

I don't, but I do consider almost every application of ternary to result
in too-dense code, which is why I'm ecstatic not to have them.
more readable and harder to get wrong, unlike your sparse example,
which has 'foo' on both branches of the conditional where you meant
'foo' and 'bar'.

....as several people already noticed, proving the great readability of
the sparse way of expressing oneself...


Alex
 
M

Martin Maney

Read PEP 308, and note that this was probably the largest flamewar in

BTW, is there ever going to exist the promised summary of the reasons
the PEP was rejected despite a 4:1 vote favoring it? It was a fine bit
of sophistry for the BDFL (or whoever ran the thing) to split the
supporting votes so that it looked like there was a lack of consensus
on substantial issues rather than the superficial difference of taste
that actually made the discussion so... active. I've been wondering
ever since how that would be spun in the final apologia.
 
M

Martin Maney

....as several people already noticed, proving the great readability of
the sparse way of expressing oneself...

Amazing. If a typo slips into something you dislike then you cite that
as proof of how bad it is. When it happens to you while showing off
your preferred form, it becomes, by prestidigitation, proof of how good
that is. Clearly this is determined by nothing at all like logic.
 
A

Alex Martelli

Martin Maney said:
Amazing. If a typo slips into something you dislike then you cite that
as proof of how bad it is. When it happens to you while showing off
your preferred form, it becomes, by prestidigitation, proof of how good
that is. Clearly this is determined by nothing at all like logic.

It's not the typo that "becomes proof" (or, rather, indication) of the
higher readability of sparse expression: it's the fact that so many
readers noticed it and let me know, privately or publically. Why do you
think it's illogical to observe that? Typos and other errors are easier
to see when they're part of very readable code than when they're part of
dense, obfuscated code -- seems perfectly logical to me.

Anything that requires the same name (or whatever) to be entered more
than once can be subject to more typos than a form in which you enter
the information only once -- ameliorating which is a better chance for a
human reader to catch a typo due to the redundancy (while if the info is
entered only once there is no such redundancy and any catch needs to be
based on deeper understanding). This might be relevant, say, when
discussing <name> += <value> vs <name> = <name> + <value> -- when <name>
is sufficiently complicated the second form may have such issues which
the first one avoids, and there's no real chance of introducing a short,
simple temporary name to ameliorate things. This is not quite germane
to the discussion at hand, though.


Alex
 
M

Martin Maney

Alex Martelli said:
It's not the typo that "becomes proof" (or, rather, indication) of the
higher readability of sparse expression: it's the fact that so many
readers noticed it and let me know, privately or publically. Why do you

Okay, let me unpack the thought more fully (as I should have done since
I was jumping on a weeks-old thread).

There's a recurring argument, seen most often when dissing a usage one
disagrees with (you're not by a long shot the only one who uses this,
BTW). One grabs typos in ones opponents' examples and construes them
as evidence of the inferiority of whatever it is one dislikes about
their example, usually a stylistic quirk or a proposed change. This is
a dubious argument on the face of it because it is so clearly
selective: when a typo occurs in a stylistically orthodox chunk of
code, it is nearly always regarde as being just a typo, not evidence of
some deeper problem with the style. To properly ground this argument
one would need to be an honest statistician and consistently account
for typos in both orthodox and unorthodox code; even then, any imputed
evidence against the unorthodox should account for the natural tendency
to make more errors with the unfamiliar than with the familiar, as well
as the impossibility of testing code (something we are constantly
advised to do, both explicitly and implicitly) that uses features not
currently available in the language.

This new excuse for a typo in well-regarded, orthodox examples seems to
rest upon a similarly weak foundation. At least I cannot ever recall
seeing anyone who had used the above attack retract it when a dozen of
his comrades turned out to have pointed out the same flaw at about the
same time, but surely that is no less proof of the readability of a
usage that one dislikes than it is on one's favorite tricks, eh? :-/

Ugh! That's far more words than this deserves, if not that the dubious
argument is being wielded by someone whose opinions deservedly carry a
lot of weight here.
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

No members online now.

Forum statistics

Threads
473,744
Messages
2,569,482
Members
44,901
Latest member
Noble71S45

Latest Threads

Top