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