Matimus schrieb:
The expr in that "raises" clause should be a list of Exceptions.
You are clearly confusing the annotation feature with a possible
application of the annotation feature. Annotation could be used for
many different applications besides type safety.
Sorry, I wanted to say "*could* be a list of Exceptions". Though this is
the most obvious application. In the end, the annotations need to be
given a semantical meaning anyway.
Annotation simply creates a dictionary. The name `return` was chosen
for the return value because it _is_ a keyword and therefore could not
conflict with the name of any of the parameters. Using "raises" would
mean that we would have to introduce the name "raises" as a new
keyword. It would be better just to use they existing keyword "raise".
Yes, it later also occured to me that it ought to be an existing
keyword, i.e. "raise" (or maybe "except"). That's porbably the reason
why it is "throw" in C++, and not "throws".
With all of that being said, a package or application that uses
annotation could simply use the data-structure associated with
"return" to also contain exception information. That might not seem
intuitive, but keep in mind that the value associated with "return" in
the associations dictionary is going to be a special case anyway.
def foo(a: "a info", b: "b info") -> "return info", "exception info":
return "hello world"
That would be possible. But I still think it makes sense to separate
them, like so:
def foo(a: "a info", b: "b info") -> "ret info" raise "exc info":
return "hello world"
And then the annotation dictionary would contain another key "raise"
containing the exc info. This cannot conflict with the name of any other
parameter either.
Maybe the following syntax would be even more intuitive:
def foo(a: "a info", b: "b info") return "ret info" raise "exc info":
return "hello world"
I don't know how determined the "->" syntax is already.
-- Christoph
--
http://mail.python.org/mailman/listinfo/python-list
