Guido van Rossum wrote:

Dear developers,

Eric Raymond has sent me the following patch, which adds conditional expressions to Python. I'd like to hear opinions on whether this is a good thing to add to Python, and whether this is the right syntax.

Yee ha! I think that this is a great idea. I'm surprised that using the colon doesn't cause problems. I'm not a grammer lawyer, and don't care that much. I very much would like to see a conditional expression. I wouldn't object if it was spelled differently than C's.

I am a bit skeptical about whether this is sufficiently Pythonic, but on the other hand there have always been requests for such a feature, and the existing solutions are ugly:

a and b or c

only works when you know for sure that b will never be false, and > > (a and [b] or [c])[0]

is dead ugly...

Yup. (a and (b,) or (c,))[0] is even worse. ;) Jim -- Jim Fulton mailto:jim@digicool.com Technical Director (888) 344-4332 Python Powered! Digital Creations http://www.digicool.com http://www.python.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Jim Fulton :

...

I'm surprised that using the colon doesn't cause problems.

[ESR]

Pgen doesn't tag this ambiguous. The LL(1) traversal actually helps here; by the time you see a colon, you already know whether or not you're parsing a ternary telect.

Interestingly, the very ad-hoc parsing that I described in the compiling/parsing session on devday would be hit by this... I was looking for a colon at nesting level zero. Serves me right for not using a real parse :-) --Guido van Rossum (home page: http://www.python.org/~guido/)

Tim Peters :

If this goes in (I'm not deadly opposed, just more opposed than in favor), I'd like to see "else" used instead of the colon (cond "?" true "else" false). The question mark is reasonably mnemonic, but a colon makes no sense here.

I have to say that I think any ternary syntax that mixes a single-character operator with a keyword would be intolerably ugly.

Now let's see whether people really want the functionality or are just addicted to C syntax <ahem>.

It's not that simple. People clearly want the functionality; we've seen ample evidence of that. Given that, I think the presumption has to be in favor of using the familiar C syntax rather than an invention that would necessarily be more obscure.

BTW, a number of other changes would be needed to the Lang Ref manual (e.g., section 2.6 (Delimeters) explicitly says that "?" isn't used in Python today, and that its appeareance outside a string literal or comment is "an unconditional error"; etc).

I'm certainly willing to fix that. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> [The disarming of citizens] has a double effect, it palsies the hand and brutalizes the mind: a habitual disuse of physical forces totally destroys the moral [force]; and men lose at once the power of protecting themselves, and of discerning the cause of their oppression. -- Joel Barlow, "Advice to the Privileged Orders", 1792-93

[Tim, tosses off cond "?" true "else" false in apparent hatred of colons] [Eric S. Raymond]

I have to say that I think any ternary syntax that mixes a single-character operator with a keyword would be intolerably ugly.

It's certainly not attractive <wink>. Guido is the Master of Syntax; if he decides the functionality is Pythonic, he'll dream up a good Pythonic syntax. I'll refrain from suggesting "if" cond "lambda" true "else" false <wink>.

...

Now let's see whether people really want the functionality or are just addicted to C syntax <ahem>.

It's not that simple. People clearly want the functionality; we've seen ample evidence of that.

I have not. Really! This has been debated for nearly a decade, with no consensus (the invention of the (a and [b] or [c])[0] atrocity predates c.l.py!). *Some* people certainly want ?: (or equivalent) a lot; but others are equally opposed. Note that lack of ?: didn't have enough of a constituency in Andrew Kuchling's eyes either to make his original "Python Warts" paper, or its revisions: http://starship.python.net/crew/amk/python/writing/warts.html No change ever proposed has failed to attract vocal & persistent supporters, so it's not as simple as *that* either <0.5 wink>.

Given that, I think the presumption has to be in favor of using the familiar C syntax rather than an invention that would necessarily be more obscure.

By count, I'm sure many more languages (from virtually all functional languages to Icon) use "if cond then true else false" for this purpose; obscurity is relative to your background. At least "if x then y else z" is clear on the face of it (which may betray my background <wink>). "then" has no chance of getting into Python1, though. My core objection is that ?: doesn't "look pretty": it's not at all suggestive of what it means, and the effects on precedence and associativity are unattractive ("see C, copy C" is the only sense there is to it, and rules for ?: are-- as I noted last time --obscure). Good syntax counts for a lot in Python -- which is why it doesn't look like C now. Get a good syntax, and most of my objections vanish; I don't have a good syntax to suggest, though. passing-the-ball-back-to-guido-where-he-always-knew-it- would-land<wink>-ly y'rs - tim

Christopher Petrilli :

The question comes from what "problem" you're trying to solve. The ?: syntax does not introduce any new "functionality" to the language, nor does it make it capable of solving problems or requirements that it can not do at the current time.

Well, in a theoretical sense, you're right. But then, even troff macros and INTERCAL are Turing-complete <my-first-attempt-at-a-Tim-Peters-style-wink>. One of the lessons of Python to this old LISPer is that *notation matters*. Theoretically, Python is a subset of Scheme-with-objects using a vaguely C-like surface notation. But even I would rather write a for-loop than the equivalent recursion. That's why I code in Python now instead of trying to rescue LISP from its desuetitude. So while it is *theoretically* true that ?: adds nothing, it is *practically* true that it enables a large class of idioms that can't otherwise be comfortably expressed. That matters. Now, you can argue that the complexity ?: adds to language is not paid for by the additional convenience; I disagree, but that's at least a defensible argument. But simply saying it "adds nothing to the language" is a red herring -- neither do many of the other base language features. Why, for example, do we have more than one kind of loop construct? Unecessary. Wasteful. Clearly either "for" or "while" must go. As an exercise, try editing your complaint so that it refers to "for" everywhere it now refers to ?:. Contemplate the edited version until you achieve enlightenment ;-). -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> The same applies for other kinds of long-lasting low-level pain. [...] The body's response to being jabbed, pierced, and cut is to produce endorphins. [...] So here's my programme for breaking that cycle of dependency on Windows: get left arm tattooed with dragon motif, buy a crate of Jamaican Hot! Pepper Sauce, get nipples pierced. With any luck that will produce enough endorphins to make Windows completely redundant, and I can then upgrade to Linux and get on with things. -- Pieter Hintjens

[Christopher Petrilli]

... Python is not a language that has been optimized for "minimal typing", it's much more verbose than most languages, and so that argument shouldn't be applied.

Concise expression of common concepts is a Good Thing, though, and there's nothing inherently evil about wanting one of two outcomes <wink>. My impression is that the people historically most in favor of ?: ("or something like it") are also the ones most strongly in favor of embedded assignment ("or something like it"), and I can't *dismiss* either gripe. The Python while 1: x = something_or_other() if not x: break consume(x) idiom is truly grating at first -- more so than the multi-line ?: alternatives, in my eyes.

Perhaps it's for optimization? That was I believe the original argument made for it in K&R, in that optimizers in that day were rather antiquated, wheras today, I believe that any C compiler would get it right if it were expressed in its full form. (Timbot?)

Indeed, a couple weeks ago we tracked down a "mysterious slowdown" of our core speech recognizer to a particular compiler failing to optimize *unless* we changed a ?: into a long winded if/else! There's really nothing you can say about "any C compiler" -- optimization is much more a black art than anyone in that business will admit to in public <0.9 wink>. C was definitely designed with "by hand" optimization in mind, and, ironically, it's those features (particularly pointer aliasing) that make it harder for compilers to optimize than is, say, Fortran. But regardless of origin, ?: stands or falls on its other merits now. Python's own implementation uses it often enough, and to good effect. So it can't be that Guido hates the idea <wink>. It's just hard to love the syntax.

So, it comes down to a few questions for me:

Does it solve a new problem? No Is it pythonic? No Does it make it faster? No

Would a nice syntax allow clearer expression of some common computations? Probably yes. That's the same basis on which, e.g., list.pop and list.extend and dict.get and 3-argument getattr and ... were adopted. "Faster" applied to those too, but nobody pushed for 'em on that basis. Clearer! That's what really matters. It's the same argument for list comprehensions too.

... Sorry if I pushed someone's buton, but... I saw a lot of hints at making Python MUCH more complex, which is counter to why I changed and dropped many other languags.

A good antitode to feature panic is reviewing Misc/HISTORY: Guido's willingness to entertain suggestions far exceeds his willingness to adopt them <wink>. it-would-be-different-if-features-were-just-as-easy-to- take-out-ly y'rs - tim

On 30 January 2000, Ka-Ping Yee said:

On Sun, 30 Jan 2000, Tim Peters wrote:

...

If this goes in (I'm not deadly opposed, just more opposed than in favor), I'd like to see "else" used instead of the colon (cond "?" true "else" false). The question mark is reasonably mnemonic, but a colon makes no sense here.

I agree with that sentiment (along the lines of the philosophy that chose "and" over "&&"), and it seems to me that it makes the most sense to use words for both:

a = x > 0 then x else -x

Yeah, I agree with Tim: it's a handy feature and I frequently wish I could do simple conditional assignment without resorting to a full-blown if/else. (I think I stumbled across "a and b or c" myself -- either that or it was suggested by *Learning Python*, but lay dormant in my subconscious for several months -- which means that I missed the "b must always be true" subtlety until it bit me. Ouch. I avoid that idiom now.) BUT the C line-noise syntax is not appropriate. It's fine in C, and it's eminently appropriate in Perl -- both languages designed to minimise wear-and-tear of programmers' keyboards. But keyboards are cheap nowadays, so perhaps we can be a bit more profligate with them. I find Ping's proposed syntax intriguing. Personally, I've always been partial to the x = if a then b else c syntax, even though I don't think I've ever used a language that includes it. (Oh wait, the toy ALGOL-knockoff that we used in Intro to Compilers had it, so I *have* written a parser and simplistic code generator for a language that includes it. Perhaps that's why I like it...) But either of these -- ie. elevate "then" to keywordhood, with or without "if", and no colons to be seen -- smell like they would play havoc with Python's grammar. And they turn a statement keyword "if" into an expression keyword. Not being at all familiar with Python's parser, I should just shut up now, but it feels tricky. And of course, any proposed syntax changes nowadays have to take JPython into account. Greg

Christopher Petrilli wrote:

The question comes from what "problem" you're trying to solve.

It would allow you to incorporate logic into expressions. There are contexts where only expressions are allowed, such as: - lambdas - DTML expr attributes in which I'd very much like to incorporate tests.

The ?: syntax does not introduce any new "functionality" to the language,

Yes it does.

nor does it make it capable of solving problems or requirements that it can not do at the current time.

Ditto.

The second qustion I'd ask is, who is this aimed at? It's certainly not aimed at first-time programmers, as I know from experience that the ?: is one of the hardest things to teach people in C (after pointers),

Hm. I can't agree. Smalltalk, came out of an essentially CP4E effort two decades ago at Xerox PARC. Smalltalk *only* had conditional expressions. The message: [condition] ifTrue: [do something ...] ifFalse: [do something else ...] is an expression in Smalltalk.

and often I leave it out of training when I did it. It's simply a "shorthand" not a new functionality.

No, it allows testing in expressions.

If its aimed at experienced programmers, I'd argue that it's at best "non-pythonic" and at worst a hack, taken from a language in which it exposes the "macro assembler" approach.

I don't agree.

Python is not a language that has been optimized for "minimal typing",

That's not the issue.

it's much more verbose than most languages, and so that argument shouldn' be applied. Perhaps it's for optimization? That was I believe the original argument made for it in K&R, in that optimizers in that day were rather antiquated, wheras today, I believe that any C compiler would get it right if it were expressed in its full form. (Timbot?)

So, it comes down to a few questions for me:

Does it solve a new problem? No

Yes.

Is it pythonic? No

Pythonicity is relative.

Does it make it faster? No

Who cares? Jim -- Jim Fulton mailto:jim@digicool.com Python Powered! Technical Director (888) 344-4332 http://www.python.org Digital Creations http://www.digicool.com http://www.zope.org Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.

Put me in the camp of "yeah, occasionally I wish I had it, but I can always hack around it, and the C syntax just blows". I'm sure if it's wedgeable into CPython it would also be in JPython, but I dislike ?: syntax enough to vote strongly against it for CPython 1.6. A Forth-ish syntax might be more acceptable x = y > z if y else z but come on! You'll give ordinarily dandruff-free Python programmers plenty of other reasons to scratch their heads with this one. head-and-shoulders-above-the-rest-ly y'rs, -Barry

On Mon, 31 Jan 2000, Fred L. Drake, Jr. wrote:

Ka-Ping Yee writes:

...

a scan through a decent chunk of Python would be useful to find out how often this construct (in its "and"/"or" incarnation) actually gets used.

I'm not sure what the survey provides other than a lower bound. I think most Python programmers who want the ?: functionality avoid the and/or approach because of the ugliness. I know I do.

Good point. Just because the workaround is bad doesn't mean the thing being worked-around is unimportant... I should weigh in to say that i have really really wanted, in particular, the ability to have a condition on the right hand side of an assignement. IIR, on some occasions it seemed less clear to have to use separate statements for what was essentially a single assignment that just, eg, differed by a single term. I wanted (want) some reasonable way to express the condition in an expression. I can see how this compactness could lead to regex-style convolution of expressions, but that could be avoided by providing a not-too-terse syntax. (I should admit that may have succumbed to the (a and (b,) or (c,))[0] grotesquerie at some point! Not sure. Wish i could recall what might have justified succumbing - the mere fact that i may have, without compelling justification, might-should disqualify my judgement on the matter, ay? Hey, maybe i didn't, i was just imagining it - now am i not a sterling judge?-) Ken klm@digicool.com

Moshe Zadka :

...

Don't know much about DTML, but believe that being able to put conditionals in lambdas would make the latter much more useful.

Giving Guido one less reason to dislike ?: <wink>

You laugh, but this was in fact in my mind. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Nearly all men can stand adversity, but if you want to test a man's character, give him power. -- Abraham Lincoln

Moshe Zadka wrote: Seriously, I disagree with the basic premise of you and Jim: you can *already* have control structures inside experessions with and/or, so even for Jim's twisted meanings for "add new functionality to the language" it's not true.

Have you ever tried to teach this to relatively experienced programmers (never mind novices) whose background is Fortran, Modula-2, Ada, or anything other than C/C++/Java? It's *really* hard to get the idea across. I tried it in the first Python course I taught at LANL, and wound up spending 15 minutes trying to unconfuse people (and failed). Afterward, one guy said that it made even less sense than using integer offsets to fake linked lists in Fortran-77... Greg

Tim Peters :

...

... The solution can be the same as what Algol used: 'if' outside parentheses is a statement, and inside parentheses is an expression. It's a bit of a grammar rearrangement, but totally unambiguous.

If I didn't know better <wink>, I'd say there's an actual consensus here: it seems we would all agree to "(if cond then true else false)" spelling. Not to be overlooked is Christian's enhancement, allowing "elif" too (beats all heck out of guessing how ?: nests!).

Eric, are you also in agreement?

I'm not sure. I'm concerned that this syntax will actually be more viually confusing that ?:. That having been said, I am more interested in having ternary-select be in the language than I am in arguing about its exact syntax. -- <a href="http://www.tuxedo.org/~esr">Eric S. Raymond</a> Men trained in arms from their infancy, and animated by the love of liberty, will afford neither a cheap or easy conquest. -- From the Declaration of the Continental Congress, July 1775.

On Mon, 31 Jan 2000, Tim Peters wrote:

If I didn't know better <wink>, I'd say there's an actual consensus here: it seems we would all agree to "(if cond then true else false)" spelling.

Actually, i'm afraid i don't. I initially chose the "then/else" spelling specifically because "if" flags the eye to the beginning of a statement. My line of thinking was, "'then' for expressions, 'if' for statements."

I had already channeled that for the group's benefit <wink>. For 1.6, without absurd overloading of some other keyword (like "if cond def true ..."), that seems to leave

(if cond: true else false)

Sorry, i like that even less. It seems to abuse the colon, for the colon (to me) signals both (a) This Is A Statement and (b) This Begins A Block, neither of which are true here.

How much is that hated? I hate it myself, not least because I'd have to change IDLE's parser to guarantee it couldn't get confused by the colon here:

big = ( if x >= y: x else y)

I consider this a symptom of the colon-abuse i just described...

BTW, I'm not entirely convinced "then" would have to be a keyword to make "if x then y else z" work: couldn't the grammar use WORD and verify it's specifically "then" later?

Quite possibly, yes -- though i figured it wouldn't be *too* large an issue to make "then" a keyword, since i can't imagine anyone naming a symbol "then" except under the most freakish of circumstances. A quick check shows no symbol by that name in any of the Python scripts or modules we have here. -- ?!ng

On Mon, 31 Jan 2000, Tim Peters wrote:

[Tim]

...

...

If I didn't know better <wink>, I'd say there's an actual consensus here: it seems we would all agree to "(if cond then true else false)" spelling.

[Ka-Ping Yee]

...

Actually, i'm afraid i don't. I initially chose the "then/else" spelling specifically because "if" flags the eye to the beginning of a statement. My line of thinking was, "'then' for expressions, 'if' for statements."

OK, I'm baffled. I probably don't recall your suggestion -- the implication is that it didn't use the word "if"? If so, I probably read it and assumed you left out the "if" my mistake <wink>.

Yeah, my suggestion was, e.g. def abs(x): return x > 0 then x else -x Might as well summarize the other suggestions so far: return x > 0 ? x else -x return x > 0 ? x : -x return if x > 0: x else -x Have i missed any? Oh, yes, and here is the control group. return x > 0 and x or -x return (x > 0 and [x] or [-x])[0] if x > 0: return x else: return -x

Seriously, "excessively novel" isn't called for here: *tons* of languages have used if/then/else for this purpose without difficulty.

Yes, you're right about that.

No keyword has been added to Python since "lambda", and you can be certain Guido will never add another (at least not to Python1) -- this is an absolute non-starter. Ping, *you* used to know this better than anyone <wink>.

Okay, okay. You probably have a better memory about this than i do. :) Assuming that "then" will never be made a keyword, i would probably go with "x > 0 ? x else -x". "if" seems to shout "statement" too loudly at me, and colons seem too loaded. Another issue with the last suggestion: how do you explain putting a colon after the condition but not after the "else"? -- ?!ng

[Tim]

...

No keyword has been added to Python since "lambda" ...

[Greg Stein]

Actually, Tim's memory is failing. "assert" was added in 1.5. :-)

Not that this adds to the debate at all :-), but I figured that I am obligated to knock a chair leg out from under Tim every now and then.

Actually, in 1.5 Guido *removed* lambda; then he added assert; then he had second thoughts about lambda and added it again. That's why it's the last one added. You're right: the older I get the less effective my bullshit gets <wink>. Done well, young one!

p.s. I'm against a ternary operator. use an if/else statement. use def instead of lambda (lambda is the only rational basis given so far to add the operator, but it is bogus to start with)

Ah, there's nothing like the smell of consensus in the morning! Except maybe napalm.

Maybe this would be a good time to write a dozen or so examples using alternative syntaxes (syntaxii?), and stick 'em in front of a bunch of people who haven't been part of this discussion, and ask 'em "what does this do"? (Footnote: check out David Scanlan's article in the Sept. 1989 issue of "IEEE Software". Turns out that flowcharts are actually more readable than pseudocode --- the research that claimed to show otherwise was biased by (among other things) comparing structured pseudocode with spaghetti flowcharts... One li'l bit of sloppy science, and the world turns its back on something useful...) Ellipsistically yours, Greg

Greg Stein writes:

p.s. I'm against a ternary operator. use an if/else statement. use def instead of lambda (lambda is the only rational basis given so far to add the operator, but it is bogus to start with)

Actually, the places I'd use it most would be probably be in constructing parameters to string formatting operations. Grepping back in my memory, that's usually where I've wanted it. I very rarely use lambda, and usually change it on the next iteration on those cases when I do. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> Corporation for National Research Initiatives

Gordon McMillan wrote:

Fred L. Drake, Jr. writes:

...

Greg Stein writes:

...

p.s. I'm against a ternary operator. use an if/else statement. use def instead of lambda (lambda is the only rational basis given so far to add the operator, but it is bogus to start with)

Actually, the places I'd use it most would be probably be in constructing parameters to string formatting operations. Grepping back in my memory, that's usually where I've wanted it.

Boy does that ring a big bell. Was ambivalent, now I'm all for it (either C syntax or "then" syntax, don't care).

So am I! Conditional expressions make very much sense for constructing objects on-the-fly. It is quite common to denote tuples, lists and dicts directly in Python code, like so: mapping_table = { 1: "one", 2: "two", } and so on. To parameterise them, we can either use different tables embedded in an if, or use an expression inside the denotation: language = 1 mapping_table = { 1: ("one", "eins")[language], 2: ("two", "zwei")[language], } but with expressions, we get to mapping_table = { 1: language == 0 ? "one" : "eins", 2: language == 0 ? "two" : "zwei", } Well, maybe I had better chosen a different example, since the language example looks better with indexing here. How would we spell an elif? Would we at all? # languages: 0 - English 1 - German 2 - Finnish mapping_table = { 1: language == 0 ? "one" : language == 1 ? "eins", "yksi", 2: language == 0 ? "two" : language == 2 ? "zwei", "kaksi", 3: language == 0 ? "three" : language == 2 ? "drei", "kolme", } (yes the zero slot is missing - forgot what that is in Finnish:) Would conditionals also be valid on the LHS of assignments? target ? a : b = language ? "one" : "eins" grmbl - chris -- Christian Tismer :^) mailto:tismer@appliedbiometrics.com Applied Biometrics GmbH : Have a break! Take a ride on Python's Düppelstr. 31 : *Starship* http://starship.python.net 12163 Berlin : PGP key -> http://wwwkeys.pgp.net PGP Fingerprint E182 71C7 1A9D 66E9 9D15 D3CC D4D7 93E2 1FAE F6DF we're tired of banana software - shipped green, ripens at home

[Tim, makes a huge production over Guido's supposed intractability on the issue of new keywords] [Guido]

Hm, I was just thinking that 'then' wouldn't be the hardest keyword to add...

Man, you *are* Unfathomable <0.9 wink>! Even if true, you should never have admitted to it <0.1 wink>.

But I should probably stick with Tim's suggestion.

Tim would. [Ping]

...

Another issue with the last suggestion: how do you explain putting a colon after the condition but not after the "else"?

Whoever proposed that was terribly confused.

That was me. It was just brainstorming, so you wouldn't have to <wink>. i-disowned-it-in-the-same-paragraph-i-introduced-it-but- all-ideas-take-on-a-hideous-life-of-their-own-ly y'rs - tim

Guido van Rossum wrote:

Dear developers,

Eric Raymond has sent me the following patch, which adds conditional expressions to Python. I'd like to hear opinions on whether this is a good thing to add to Python, and whether this is the right syntax.

Although Eric's patch is cute, I think this language shortcut is unnecessary for Python. I'd support a do/while shortcut though ;-) It's more popular and would fit "naturally" into the language for most programmers. Overall, it seems to me that the next major version of Python needs to be cleaned, instead of being enriched. Both the language and the internals. We have enough experience already for moving in this direction. (I'm not speaking about new packages/libs or additional core facilities, like Unicode, that need to integrated). -- Vladimir MARANGOZOV | Vladimir.Marangozov@inrialpes.fr http://sirac.inrialpes.fr/~marangoz | tel:(+33-4)76615277 fax:76615252

Greg Wilson wrote:

...

[Tim] Man, you *are* Unfathomable <0.9 wink>! Even if true, you should never have admitted to it <0.1 wink>.

I think that's supposed to be <wink fraction="0.9"/>, isn't it?

not in this case. quoting a leading bot implementor: "We did requirements and task analysis, iterative design, and user testing. You'd almost think emails were an interface between people and bots." and I can assure you that proving that human beings don't like weird but formally well designed syntaxes was the easy part of that project... (but don't tell the schemers ;-) </F> "Larry Wall should be shot. Along with Bill Joy and Eric Allman." -- Daniel Finster, on comp.lang.lisp "Why, just because you guys frittered away a 20-year headstart?" -- Larry Wall