Re: [Python-Dev] Adding a conditional expression in Py3.0
(Adding python-dev back to the CC list) On 9/20/05, Jason Orendorff <jason.orendorff@gmail.com> wrote:
If there's one thing I've learned from the PEP 308 vote, it is that votes for language don't work. I prefer some discussion on Python-dev after which I pick one.
+1
Some visual aids:
return (if q: q.popleft() else: None) return (if q then q.popleft() else None) return q ? q.popleft() : None
Hmmm. Score one for ?:. But:
Why? Just because it's shorter?
menu.append( if gotHerring(): popHerring() elif gotAnyFish(): popAnyFish() else: Tofurbot())
menu.append(gotHerring() ? popHerring() : gotAnyFish() ? popAnyFish() : Tofurbot())
Here, I like the way the verbose syntax politely spreads itself out over multiple lines. In C, I never know where to put the line breaks.
Ouch. You're bringing up another valid issue: whether to support "elif". I think if we go with (if ... then ... else ...) or (if ...: ... else: ...) we'll have to support elif as well: (if ... then ... elif ... then ... else ...) or (if ...: ... elif ...: ... else: ...) I really don't like the latter. Here's a suggestion for a way to decide between a "wordy" version or C-style "?:" -- if we abandon and/or in favor of &&/||, we should also go with ?:; if we keep and/or, we should use a keyword-based conditional as well. Since so far the feedback is overwhelmingly in favor of keeping and/or, I think that settles the case in favor of a wordy version. My preference then would be (if ... then ... elif ... then ... else ...) which gives my a nice nostalgic feeling because (except for the elif part) Algol-60 had the same thing -- the first programming language I ever learned. :) (Oh, and a way to decide between colon or no colon: we're not using colons in list comps and genexprs either.) -- --Guido van Rossum (home page: http://www.python.org/~guido/)
On Tue, 2005-09-20 at 17:40, Guido van Rossum wrote:
Ouch. You're bringing up another valid issue: whether to support "elif". I think if we go with (if ... then ... else ...) or (if ...: ... else: ...) we'll have to support elif as well:
I'm not so sure. Once you start writing such a complicated thing, I think readability will favor just breaking the code out into traditional if-blocks. I'd be happy enough with just a binary condition. -Barry
Barry Warsaw wrote:
I'm not so sure. Once you start writing such a complicated thing, I think readability will favor just breaking the code out into traditional if-blocks. I'd be happy enough with just a binary condition.
Nothing prevents you from spreading the code over multiple lines, like so: x = (if a then b elif c then d else e) or even x = (if a then b elif c then d else e ) especially as there are going to be parentheses around the whole thing anyway. From a readability point of view, this is no different from if-statement blocks, and the matter is IMO not worth dumbing down an if-expression thingy as compared to its if-statement companion. -- Thomas
On Tue, 2005-09-20 at 18:21, Thomas Lotze wrote:
Nothing prevents you from spreading the code over multiple lines, like so:
x = (if a then b elif c then d else e)
or even
x = (if a then b elif c then d else e )
especially as there are going to be parentheses around the whole thing anyway. From a readability point of view, this is no different from if-statement blocks, and the matter is IMO not worth dumbing down an if-expression thingy as compared to its if-statement companion.
I guess that's my point. To me, your latter is actually worse than if a: x = b elif c: x = d else: x = e I think the conditional stuff gets the most bang for the buck in situations like: d[foo] = if a then b else c -Barry
Barry Warsaw wrote:
x = (if a then b elif c then d else e ) [...]
I guess that's my point. To me, your latter is actually worse than
if a: x = b elif c: x = d else: x = e
Can't see a difference as far as readability is concerned. But then, tastes differ.
I think the conditional stuff gets the most bang for the buck in situations like:
d[foo] = if a then b else c
And I think similar holds for LCs and GEs. Unwinding a complex sequence of for and if clauses is certainly no fun unless one is really used to it. (Which doesn't take long, though.) But your example poses another question: Up until now, I had the impression that parentheses should be mandatory around a conditional expression. There's certainly no avoiding them in situations like (if x then 1 else 2) + 3. But what about unambiguous cases like your example line? -- Thomas
On Wed, 21 Sep 2005, Thomas Lotze wrote:
Barry Warsaw wrote:
x = (if a then b elif c then d else e ) [...]
I guess that's my point. To me, your latter is actually worse than
if a: x = b elif c: x = d else: x = e
Can't see a difference as far as readability is concerned. But then, tastes differ. [...]
With the former, we have a more C-style syntax where meaning is determined purely by delimeters rather than by whitespace. Instead of braces '{' and '}', we have 'then' and 'elif'/'else'. That's a real difference. The stricter form where you don't allow 'elif' will get used in more restricted circumstances, so gives less encouragement for widespread abuse of conditional expressions by people who don't like whitespace-based syntax. John
On Tue, 20 Sep 2005, John J Lee wrote: [...]
With the former, we have a more C-style syntax where meaning is determined purely by delimeters rather than by whitespace. Instead of braces '{' and '}', we have 'then' and 'elif'/'else'. That's a real difference. [...]
Um, not clear, sorry: the "real difference" I meant to refer to above is that between delimiter-based and whitespace-based syntaxes (and not between braces and differently-spelled delimiters). John
"John J Lee" <jjl@pobox.com> wrote in message news:Pine.LNX.4.58.0509202331440.6289@alice...
The stricter form where you don't allow 'elif' will get used in more restricted circumstances, so gives less encouragement for widespread abuse of conditional expressions by people who don't like whitespace-based syntax.
I think 'abusiveness' is somewhat in the eye of the beholder here. In any case, without 'elif', one could still chain expressions by writing x = (if a then b else (if c then d else e)) which is even more Lispish. I personally think one () is enough and prefer x = (if a then b elif c then d else e) which is similar to how I wrote such things in C. Elif has the same justification here as with the statement form, where it is also unnecessary but saves nesting levels. Terry J. Reedy
On 9/20/05, Guido wrote:
On 9/20/05, Jason Orendorff <jason.orendorff@gmail.com> wrote:
return (if q: q.popleft() else: None) return (if q then q.popleft() else None) return q ? q.popleft() : None
Hmmm. Score one for ?:.
Why? Just because it's shorter?
Just a gut response to the look. The verbose forms strike me as cluttered in this particular case. In the multiline case, it doesn't look like clutter because the if/elif/else bits line up, which fits the way Python has already trained my brain.
(Oh, and a way to decide between colon or no colon: we're not using colons in list comps and genexprs either.)
(grin) Easily fixed: print "average weight:", avg(for c in chefs: c.weight) rdict = dict(for k, v in D.iteritems(): v, k) Honestly, I think I would prefer this syntax. Examples from real code, before and after: lines = [line for line in pr.block.body if line.logical_line.strip() != ''] lines = [for line in pr.block.body: if line.logical_line.strip() != '': line] row.values = \ [line[col.start:col.end].strip() for col in columns] row.values = \ [for col in columns: line[col.start:col.end].rstrip()] return [p for p in self.listdir(pattern) if p.isdir()] return [for p in self.listdir(pattern): if p.isdir(): p] -j
Jason Orendorff wrote:
Honestly, I think I would prefer this syntax. Examples from real code, before and after:
lines = [line for line in pr.block.body if line.logical_line.strip() != ''] lines = [for line in pr.block.body: if line.logical_line.strip() != '': line]
row.values = \ [line[col.start:col.end].strip() for col in columns] row.values = \ [for col in columns: line[col.start:col.end].rstrip()]
return [p for p in self.listdir(pattern) if p.isdir()] return [for p in self.listdir(pattern): if p.isdir(): p]
-1. Too much similarity with the for/if statement. People would say "why can we put a for statement in brackets but not a try statement". Reinhold -- Mail address is perfectly valid!
Guido van Rossum wrote:
I think if we go with (if ... then ... else ...) or (if ...: ... else: ...) we'll have to support elif as well:
(if ... then ... elif ... then ... else ...) or (if ...: ... elif ...: ... else: ...)
One nice thing about "x if b else y" is that it chains without needing any more keywords: x if b else y if c else z But if you require parens, it's not so nice: (x if b else (y if c else z)) -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+
Greg Ewing wrote:
Guido van Rossum wrote:
I think if we go with (if ... then ... else ...) or (if ...: ... else: ...) we'll have to support elif as well:
(if ... then ... elif ... then ... else ...) or (if ...: ... elif ...: ... else: ...)
One nice thing about "x if b else y" is that it chains without needing any more keywords:
x if b else y if c else z
But if you require parens, it's not so nice:
(x if b else (y if c else z))
If Guido chose this form, I would expect the chaining to work like chaining loops in a generator expression, with parentheses being required around the whole thing, rather than around each element in the chain: (x if b else y if c else z) The point being that the result of the conditional expression is exactly one of the options included in the expression, so only one set of parentheses is required. Regards, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com
Nick Coghlan wrote:
Greg Ewing wrote:
One nice thing about "x if b else y" is that it chains without needing any more keywords:
x if b else y if c else z
But if you require parens, it's not so nice:
(x if b else (y if c else z))
If Guido chose this form, I would expect the chaining to work like chaining loops in a generator expression, with parentheses being required around the whole thing, rather than around each element in the chain:
(x if b else y if c else z)
The point being that the result of the conditional expression is exactly one of the options included in the expression, so only one set of parentheses is required.
Either a or b could be a nested expression so it's important that it be readable in both cases. (a if e then b) ((a1 if e1 then b1) if e then b) (a if e then (a2 if e2 then b2)) ((a1 if e1 then b1) if e then (a2 if e2 then b2)) Without parentheses... (a if e then b) (a1 if e1 then b1 if e then b) (a if e then a2 if e2 then b2) (a1 if e1 then b1 if e then a2 if e2 then b2) I think the parentheses version is clearer. To me it's not as easy to picture what will happen when the condition is in the middle of the expression. Also in the above, is e1 evaluated before e? That would mean the result of e1 (a1 or b1) is thrown away if e if false. So looking at a few alternatives ... (e ? a : b) (e ? (e1 ? a1 : b1) : b) (e ? a : (e2 ? a2 : b2)) (e ? (e1 ? a1 : b1) : (e2 ? a2 : b2)) This better represents a decision tree I think. Each comparison gives one of two possible results which may be another comparison. Using keywords instead... (if e, a else b) (if e, (if e1, a1 else b1) else b) (if e, a else (if e2, a2 else b2)) (if e, (if e1, a1 else b1) else (if e2, a2 else b2)) (if e then a else b) (if e then (if e1 then a1 else b1) else b) (if e then a else (if e2 then a2 else b2)) (if e then (if e1 then a1 else b1) else (if e2 then a2 else b2)) or... possibly... (e selects a else b) (e selects (e1 selects a1 else b1) else b) (e selects a else (e2 selects a2 else b2)) (e selects (e1 selects a1 else b1) else (e2 selects a2 else b2)) I like this one, but maybe a shorter verb would be nice. Other possible words might be "gives", "chooses" or "picks". With the (e?a:b) syntax, I tend to want to switch the '?' and ':' here so that the colon is more consistent with how Python uses it. (e: a ? b) (e: (e1: a1 ? b1) ? b) (e: a ? (e2: a2 ? b2)) (e: (e1: a1 ? b1) ? (e2: a2 ? b2)) That may be more confusing to those who are use to 'C', but clearer to those who use Python as their main programming language. The '?' becomes an 'else' which might be useful in other expressions. Without the colon ... (e selects a ? b) (e selects (e1 selects a1 ? b1) ? b) (e selects a ? (e2 selects a2 ? b2)) (e selects (e1 selects a1 ? b1) ? (e2 selects a2 ? b2)) Or if e evaluates an integer... :-) (e selects a, b, c, ...) I think this would be quite useful and would work perfectly well with boolean expressions as well. The advantage here is that a,b,c etc.. would not be pre evaluated as they are when you use a list or dictionary. (e selects a, b) (e selects (e1 selects a1, b1), b) (e selects a, (e2 selects a2, b2)) (e selects (e1 selects a1, b1), (e2 selects a2, b2)) ( e selects (e1 selects a1, b1), (e2 selects a2, b2), (e3 selects a3, b3) ) Being able to have more than two alternative may reduce the need to nest or chain them in some cases. A variation might be to have negative index's pick from the far end just as list index's do. This would be my choice although I wasn't thinking of it when I started this reply. ;-) Cheers, Ron
Adam wrote:
So looking at a few alternatives ...
[snip]
(e ? (e1 ? a1 : b1) : (e2 ? a2 : b2))
[snip]
(if e, (if e1, a1 else b1) else (if e2, a2 else b2))
[snip]
(if e then (if e1 then a1 else b1) else (if e2 then a2 else b2))
[snip
(e selects (e1 selects a1 else b1) else (e2 selects a2 else b2))
[snip]
(e: (e1: a1 ? b1) ? (e2: a2 ? b2))
[snip]
(e selects (e1 selects a1 ? b1) ? (e2 selects a2 ? b2))
[snip]
(e selects (e1 selects a1, b1), (e2 selects a2, b2))
Please no more syntax proposals! There were enough in the PEP. It looks like most people support a conditional expression of some sort. We need to leave the syntax to Guido. We've already proved that like the decorators discussions, we can't as a community agree on a syntax. That's what we have a BDFL for. =) Steve -- You can wordify anything if you just verb it. --- Bucky Katt, Get Fuzzy
On 9/21/05, Steven Bethard <steven.bethard@gmail.com> wrote:
Please no more syntax proposals! There were enough in the PEP. It looks like most people support a conditional expression of some sort. We need to leave the syntax to Guido. We've already proved that like the decorators discussions, we can't as a community agree on a syntax. That's what we have a BDFL for. =)
Another QOTFcandidate! -- --Guido van Rossum (home page: http://www.python.org/~guido/)
Guido: When you invited resumed discussion, did you intend to proceed from where the revised PEP left off (with a few variations on the table), or to start over from point zero (with potentially anything and everything on the table). In particular, do we need to rehash the reasons for rejection of the backwards if-else proposal that a few seem to wish to resurrect? Many people, perhaps most, including me, read exp1 if exp2 else exp3 # as cond if etrue else efalse # in direct analogy with cond ? etrue : efalse # from C I mentally read ?: in C as if/else! It took a few readings of the proposal to even realize that it the order flipped. There there is the obvious analogy with Python's if cond: etrue else: efalse with 'if' moved over to the first : position (and the : then removed) but with 'else' still between the alternatives (and the second : also removed). Then there are conditional functions, in various languages, iff(cond, etrue, efalse), which as far as I know always have the expressions in that order. Need I continue? Or is the dead still dead? Terry J. Reedy
I think a recap of past arguments is useful. Me-too votes are not. i will read everything and pick a syntax and that's it. We can do it in Python 2.5. On 9/21/05, Terry Reedy <tjreedy@udel.edu> wrote:
Guido:
When you invited resumed discussion, did you intend to proceed from where the revised PEP left off (with a few variations on the table), or to start over from point zero (with potentially anything and everything on the table). In particular, do we need to rehash the reasons for rejection of the backwards if-else proposal that a few seem to wish to resurrect?
Many people, perhaps most, including me, read
exp1 if exp2 else exp3 # as cond if etrue else efalse # in direct analogy with cond ? etrue : efalse # from C
I mentally read ?: in C as if/else! It took a few readings of the proposal to even realize that it the order flipped.
There there is the obvious analogy with Python's if cond: etrue else: efalse with 'if' moved over to the first : position (and the : then removed) but with 'else' still between the alternatives (and the second : also removed).
Then there are conditional functions, in various languages, iff(cond, etrue, efalse), which as far as I know always have the expressions in that order.
Need I continue? Or is the dead still dead?
Terry J. Reedy
_______________________________________________ Python-Dev mailing list Python-Dev@python.org http://mail.python.org/mailman/listinfo/python-dev Unsubscribe: http://mail.python.org/mailman/options/python-dev/guido%40python.org
-- --Guido van Rossum (home page: http://www.python.org/~guido/)
Need I continue? Or is the dead still dead?
Since 'a if b else c' is not obviously dead, I will summarize my argument against it thusly: It is ambiguous to people because it is can be parsed (by people, who are not automatons) as either '(a if) b (else c)' or 'a (if b) (else c)'. The first parsing, seeing a as the conditional rather than the consequent, as in the the second, is at least as reasonable as the second given precedents in both other algorithm languages and natural languages (in English, at least, but I suspect others also). Ambiguity sometimes leads to discomfort. As important, it sometimes leads to bugs either in writing or reading. The impetus for this discussion was a real-life buggy example of the and/or construct. Its replacement should be something not similarly bug-prone, even if for a different reason. Terry J. Reedy
Terry Reedy wrote:
Many people, perhaps most, including me, read
exp1 if exp2 else exp3 # as cond if etrue else efalse # in direct analogy with cond ? etrue : efalse # from C
I'd have thought only Forth programmers would be prone to that! It would surprise me greatly if it's really true that *most* people would read it that way. Especially given that, in real code, you're not going to be looking at abstract names like exp1, exp2, exp3, but (hopefully) something a lot more meaningful. Can you honestly say that you would read return red_value if color == 'red' else blue_value as if red_value: return color == 'red' else: return blue_value ? -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+
"Greg Ewing" <greg.ewing@canterbury.ac.nz> wrote in message news:433223A8.3010400@canterbury.ac.nz...
Terry Reedy wrote:
Many people, perhaps most, including me, read
exp1 if exp2 else exp3 # as cond if etrue else efalse # in direct analogy with cond ? etrue : efalse # from C
I'd have thought only Forth programmers would be prone to that!
Never wrote a single line, and may have not read one (in DDJ? Byte?) for 15-20 years. How do *you* read such C? Cond 'Qmark' ....?
It would surprise me greatly if it's really true that *most* people would read it that way.
OK. I withdraw 'possibly most' as not directly relevant. It would not take that many people to have enough people mistakenly write or read it that way for this construct to be somewhat as bug prone, in practice, as and/or. During the c.l.p debate, someone counted about 100 correct uses of 'a and b or c' in the standard library. But one real misuse edged Guido toward replacing it. So I think the replacement should be as clear as reasonably possible and clearly an improvement.
Especially given that, in real code, you're not going to be looking at abstract names like exp1, exp2, exp3, but (hopefully) something a lot more meaningful.
Because every object in *Python* (ignoring buggy or unusual __nonzero__ methods) has a boolean value, any expression can be a conditional expression and hence conditional expressions often lack a boolean operator to flag the expression as the likely conditional.
Can you honestly say that you would read
Given that setup, how could I possible misread :-?
return red_value if color == 'red' else blue_value as if red_value: return color == 'red' else: return blue_value ?
I can imagine that if I were to read the return naively, I might wonder whether the expressions were reversed. And certainly, not all code I have read has had such obvious names. Now, can you honestly say that you would (naively) read return foo if bar else baz and be certain you knew what it meant? Terry J. Reedy
Terry Reedy wrote:
During the c.l.p debate, someone counted about 100 correct uses of 'a and b or c' in the standard library. But one real misuse edged Guido toward replacing it. So I think the replacement should be as clear as reasonably possible and clearly an improvement.
But I think there's a difference in kind here - to *fix* Raymond's example required a fundamental change to the structure of the line, none of which looked as clean as the original. There is no way to get the and/or construct to gracefully handle the case where the desired result in the 'true' case might itself be false: either you change to using an if statement, or you use a workaround like the ugly singleton-list approach. That is, the following is fundamentally broken for pure imaginary numbers: return isinstance(z, ComplexType) and z.real or z Fixing it requires changing to either: return (isinstance(z, ComplexType) and [z.real] or [z])[0] or: if isinstance(z, ComplexType) return z.real else: return z This is not the case with an in-fix notation for conditional expressions - you can fix a broken line simply by moving the relevant expressions to the correct locations. return isinstance(z, ComplexType) if z.real else z # Broken! return z.real if isinstance(z, ComplexType) else z # Correct! I see this as being in the same category of error as writing "return foo ** baz" when you really should have written "return baz ** foo" (i.e., not the language's problem). (Random aside: it would be nice if "foo ** bar % baz" automatically invoked the three argument form of 'pow')
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
Yes. I'd expect it to read like English - "Return foo if bar is true, otherwise return baz". Whether that was was what code was *supposed* to be doing, I couldn't assess without additional context (but that is true regardless of the syntax). With the prefix notation used for C's conditional operator, I simply don't read it in the order it's written - I read "return bar ? foo : baz" as "if bar is true then return foo, otherwise return baz". That's possible with C because it uses punctuation - using an English keyword instead makes it significantly harder for me to consider interpreting the construct that way (In fact, the only way I can get my brain to accept it is by mentally replacing the "if" with "?" and the "else" with ":"). Does it help if you think of "if <C> else" as a parameterised infix operation for choosing between the expressions on either side? Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia --------------------------------------------------------------- http://boredomandlaziness.blogspot.com
On 9/23/05, Nick Coghlan <ncoghlan@gmail.com> wrote:
But I think there's a difference in kind here - to *fix* Raymond's example required a fundamental change to the structure of the line, none of which looked as clean as the original. There is no way to get the and/or construct to gracefully handle the case where the desired result in the 'true' case might itself be false: either you change to using an if statement, or you use a workaround like the ugly singleton-list approach.
That is, the following is fundamentally broken for pure imaginary numbers: return isinstance(z, ComplexType) and z.real or z
It's hard to say whether this fixes Raymond's example when the goal wasn't clearly stated, but I find a non ternary option lambda z: complex(z).real more readable than any of the variants proposed so far. The obvious downsides are that it can raise a ValueError, and turns integers into floats. But if the input list is all numeric, it has clean results. -- Michael Urman
"Nick Coghlan" <ncoghlan@gmail.com> wrote in message news:4334DD43.1010207@gmail.com... <snip discussion indicating that our brains work different on this issue> I am reminded of how some people seem to react to fingernails on a blackboard, while the screech is just another noise to me, except that I am in the opposite position with respect to a if b else c.
Does it help if you think of "if <C> else" as a parameterised infix operation for choosing between the expressions on either side?
Hmm. If I parse it as a (if b else) c and sort of ignore the words and think of it as <T c F> so that the whole thing is a switch pointing either left or right? A bit strange, but perhaps it does. Terry J. Reedy
Terry Reedy wrote:
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
I can honestly say that, given I knew I was reading Python code, it would never have entered by head to read "foo if" as meaning that "foo" was the condition. Bizarrely backwards too much it would be. Greg
On 9/24/05, Terry Reedy <tjreedy@udel.edu> wrote:
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
FWIW, yes, I can honestly say that I would be certain. Yes, you may be able to *parse* it as (foo if) bar (esle baz) as well as foo (if bar) (else baz), but I know of no conceivable *semantic* meaning for "foo if" - English has no postfix if, and nor do any programming languages, except entirely postfix ones such as Forth. Paul.
On Saturday 2005-09-24 04:21, Terry Reedy wrote:
Never wrote a single line, and may have not read one (in DDJ? Byte?) for 15-20 years. How do *you* read such C? Cond 'Qmark' ....?
I seldom have to read C code aloud, and the ?: operator is rare-ish; but I would suggest reading a?b:c as "a chooses b else c" or (shaving a syllable) "a gives b else c" or something like that. Or, ploddingly but unambiguously, "a query b colon c".
Now, can you honestly say that you would (naively) read
return foo if bar else baz
and be certain you knew what it meant?
I can't imagine *actually* reading it as if "foo" were the condition. But I can imagine reading it, to begin with, as if it were a Perlish conditionalized statement: "(return foo) if bar else ... aw heck, that can't be right". Which is probably benign but slows down comprehension. -- g
I don't remember where I read (here around probably) that having a "client pluggable" syntax was not good for python because then ,and more blah blah.I believed it was a rule of the thumb.. But ,when a client programmer like me writes code he tries to give a clean, unambigous interface/syntax for a possible under user.Having a fixed set of keywords and not overridable syntactic sugar is just a limit.Once a sound set of unittest is written with documentation, every useful library would add its keywords. What I start thinking reading here is that if you let redefine, instead: 1) print statement :I will redefine it like now , no matter if python 3.0 is not selling it any more in the language 2) on A take B or C: How ever and whatever one would like to write, this expression could be definable, ending all the pathetic blah blah (hope not to offend) Thanks for jour job anyway. Paolino
Steven Bethard wrote:
Please no more syntax proposals! There were enough in the PEP. It looks like most people support a conditional expression of some sort. We need to leave the syntax to Guido. We've already proved that like the decorators discussions, we can't as a community agree on a syntax. That's what we have a BDFL for. =)
No problem, I'll go back to watching this interesting discussion and see what happens. :-) I really should have deleted all but the last one anyway and probably should have moved it to python-list at that point since it's quite different from whats being proposed I think. Cheers, Ron
Ron Adam wrote:
(a if e then b) ((a1 if e1 then b1) if e then b) (a if e then (a2 if e2 then b2)) ((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all those, don't you? -- Greg Ewing, Computer Science Dept, +--------------------------------------+ University of Canterbury, | A citizen of NewZealandCorp, a | Christchurch, New Zealand | wholly-owned subsidiary of USA Inc. | greg.ewing@canterbury.ac.nz +--------------------------------------+
Greg Ewing wrote:
Ron Adam wrote:
(a if e then b) ((a1 if e1 then b1) if e then b) (a if e then (a2 if e2 then b2)) ((a1 if e1 then b1) if e then (a2 if e2 then b2))
I think you mean 'else' rather than 'then' in all those, don't you?
Yes of course, thanks for correcting.
participants (15)
-
Barry Warsaw -
Gareth McCaughan -
Greg Ewing -
Guido van Rossum -
Jason Orendorff -
John J Lee -
Michael Urman -
Nick Coghlan -
Paolino -
Paul Moore -
Reinhold Birkenfeld -
Ron Adam -
Steven Bethard -
Terry Reedy -
Thomas Lotze