[Python-ideas] exception based conditional expression, similar to if-else conditional expression

[Ron Adam]

Steven D'Aprano wrote:
> On Sat, 22 Aug 2009 11:28:04 am Ron Adam wrote:
>> Greg Ewing wrote:
>>> Steven D'Aprano wrote:
>>>> Others have suggested that the colon should be dropped. I dislike
>>>> that idea, because there's nothing but whitespace delimiting the
>>>> list of exceptions from the except-expression:
>>>>
>>>> EXPR except EXCEPT-LIST EXCEPT-EXPR
>>> I agree. Even if it can be parsed unambiguously, it's
>>> going to seem weird and confusing to a human.
>>>
>>> So far I haven't seen anything I like better than
>>>
>>>   <expr> except <value> if <exception>
>>>
>>> despite the fact that it uses the words 'except'
>>> and 'if' in a different way than elsewhere.
>> Possibly the only way to do this within those constraints 
> 
> Which constraints? Are you referring to the fact that any proposed 
> syntax must be capable of being unambiguously parsed?

And also to not using 'except' and 'if' in a different way than elsewhere.


>> is a purely syntactic.
> 
> I'm not sure I understand. Can you give an example of a proposal which 
> *isn't* syntactic?

Technically you are correct, but I was trying to refer to patterns that do 
not use keywords to identify the operation.  For example slice operations 
use a pattern rather than a unique symbol to identify the operation.

So this is an example of a pattern that could work.

>>      value = (expr1 :exception: expr2)

> Are the brackets intended to be part of the syntax, or are they there 
> just for grouping? In other words, would this be allowed?

Yes, I intended the brackets to be part of the pattern.


> value = function(expr1 :exception: expr2)
> 
> Or would we have to write this?
> 
> value = function((expr1 :exception: expr2))

I supose it could work like generator expressions do.  Then both of these 
could be equivalent.


>> Sense most people (and editors) recognize exceptions names easily,
>> there really isn't a strong need to use the key word "except" in an
>> expression like this.
> 
> The word "except" cues in the reader that they are seeing an 
> exception-expression, rather than some sort of data structure like 
> {key:value} or (a, tuple).

True, it needs to be unique enough to be easily identifiable or it would 
not be worth it.


> For the same reason, list comprehensions use "for":
> 
> [x+1 for x in alist]
> 
> rather than mathematical notation:
> 
> {x+1 ∀ x ∈ alist}

It displayed fine.  :-)

> (if that doesn't display for you, the first odd character is an upside 
> down A, "for all", and the second is a curved E, "element of"). If you 
> don't like unicode-based source code, we could replace the "for all" 
> and "element of" symbols with colons:
> 
> [x+1 : x : alist]

I think having the square brackets with the colons would be a bit too close 
to slice notation here.  ie... it's not unique enough to be easily 
identifiable.


> but we don't because the words "for" and "in" give the reader hints as 
> to what is being done, which a colon would not.

This is especially true for more complex operations such as looping and 
repeating.


> Words are just symbols, so anytime you have syntax including a keyword, 
> you could replace the keyword with a symbol. That way leads to APL. As 
> a general rule, keywords are more readable, punctuation is more 
> concise.

Yes, I agree, but python isn't that strict about everything.  To me a well 
defined exception expression that



All the previous suggestions view the term as needing three values, so you 
need two separators along with unique symbols (or keywords) to come up with 
something that fits the need in a clear and concise way.  I was thinking 
what if we could use the exception object itself as an operator, then the 
term becomes even simpler and more concise.  But the only way I can think 
to do that in a clear way is to use syntax to identify the exception, such 
as putting colons, or some other symbol around the exception.  <shrug>


Ron