Missing exceptions in PEP 3107
cito at online.de
Sun Aug 10 13:18:58 CEST 2008
>> 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
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.
More information about the Python-list