Inline Conditionals?

[Joshua Ginsberg]

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

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

Thanks!

-jag

--
Joshua Ginsberg <jo***@brainstorminternet.net>
Brainstorm Internet Network Operations

[Adonis]

"Joshua Ginsberg" <jo***@brainstorminternet.net> wrote in message
news:ma**************************************@pyth on.org...

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

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

Thanks!

-jag

--
Joshua Ginsberg <jo***@brainstorminternet.net>
Brainstorm Internet Network Operations

How about something like:

def iif(condition, true=True, false=False): .... if condition:
.... return true
.... return false
.... iif('foo' == 'bar', 'w00t', 'l33t') 'l33t' iif('bar' == 'bar', 'w00t', 'l33t') 'w00t' iif('bar' == 'bar') True iif('foo' == 'bar') False

Hope this helps.

Adonis

[Chris Dutton]

Adonis wrote:

How about something like:

def iif(condition, true=True, false=False):

... 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.

[Michael Hudson]

Joshua Ginsberg <jo***@brainstorminternet.net> writes:

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

--
Linux: Horse. Like a wild horse, fun to ride. Also prone to
throwing you and stamping you into the ground because it doesn't
like your socks. -- Jim's pedigree of operating systems, asr

[Peter Hansen]

Joshua Ginsberg wrote:

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

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

This is a FAQ:
http://www.python.org/doc/faq/progra...rnary-operator

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

[Alex Martelli]

Peter Hansen <pe***@engcorp.com> wrote:

Joshua Ginsberg wrote:

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

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

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

[Antoon Pardon]

Op 2004-08-26, Alex Martelli schreef <al*****@yahoo.com>:

Peter Hansen <pe***@engcorp.com> wrote:

Joshua Ginsberg wrote:

> Is there any plan to include inline conditionals in Python? For example:
>
> def isNegative(x):
> return x < 0 ? True : False

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.

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 ]

--
Antoon Pardon

[JCM]

Antoon Pardon <ap*****@forel.vub.ac.be> wrote:

Op 2004-08-26, Alex Martelli schreef <al*****@yahoo.com>: ....

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 ]

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...)

[John J. Lee]

al*****@yahoo.com (Alex Martelli) writes:
[...]

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

[Alex Martelli]

Antoon Pardon <ap*****@forel.vub.ac.be> wrote:
...

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

[Paul Rubin]

al*****@yahoo.com (Alex Martelli) writes:

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.

[Alex Martelli]

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

al*****@yahoo.com (Alex Martelli) writes:

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

[Martin Maney]

Michael Hudson <mw*@python.net> wrote:

Joshua Ginsberg <jo***@brainstorminternet.net> writes:

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

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.

--
The dualist evades the frame problem - but only because
dualism draws the veil of mystery and obfuscation
over all the tough how-questions -- Daniel C. Dennett

[Martin Maney]

Alex Martelli <al*****@yahoo.com> wrote:

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

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...

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.

--
Their arguments, being based not in reason, are immune to it.

[Alex Martelli]

Martin Maney <ma***@pobox.com> wrote:

Alex Martelli <al*****@yahoo.com> wrote:

Paul Rubin <http://ph****@NOSPAM.invalid> wrote:

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...

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

[Martin Maney]

Alex Martelli <al*****@yahoo.com> wrote:

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.

--
People make secure systems insecure because
insecure systems do what people want and
secure systems don't. -- James Grimmelmann