在PEP 3107中缺少例外 [英] Missing exceptions in PEP 3107
问题描述
我只是在阅读PEP 3107（功能注释），并想知道为什么
例外没有提到那里。我认为如果一个
可以指定一个函数可以引发哪些异常会有所帮助，类似于
如何在C ++中使用throw引用它。条款。语法是
这样的东西：
def foo（a：expr，b：expr = 5）引发expr -expr：
expr中的引发子句应该是一个例外列表。
单独作为注释的可能例外列表将是
已经有用。当然也可以讨论Python
是否应该检查函数是否真的只引发了这些异常（如C ++中的
），或者我们甚至可以检查异常（如在Java中，但这个
似乎是一个有争议的问题。）
这已经讨论过，还是在不同的PEP中？
- Christoph
I''m just reading PEP 3107 (function annotations) and wonder why
exceptions are not mentioned there. I think it would be helpful if one
could specify which exceptions can be raised by a function, similarly to
how it is possible in C++ using the "throw" clause. The syntax would be
something like this:
def foo(a: expr, b: expr = 5) raises expr -expr:
The expr in that "raises" clause should be a list of Exceptions.
Having the list of possible exceptions as annotation alone would be
already helpful. Of course it could be also discussed whether Python
should check that the function really raises only these exceptions (as
in C++), or we could even have checked exceptions (as in Java, but this
seems to be a controversial issue).
Has this already been discussed, or is it in a different PEP?
-- Christoph
推荐答案
8月9日上午9：08 *，Christoph Zwerschke< c .. 。@ online.dewrote：
On Aug 9, 9:08*am, Christoph Zwerschke <c...@online.dewrote:
我只是在阅读PEP 3107（功能注释）并想知道为什么
例外没有在那里提到。我认为如果一个
可以指定一个函数可以引发哪些异常会有所帮助，类似于
如何在C ++中使用throw引用它。条款。语法是
这样的东西：
def foo（a：expr，b：expr = 5）引发expr -expr：
expr中的引发子句应该是一个例外列表。
单独作为注释的可能例外列表将是
已经有用。当然也可以讨论Python
是否应该检查函数是否真的只引发了这些异常（如C ++中的
），或者我们甚至可以检查异常（如在Java中，但这个
似乎是一个有争议的问题。）
这已经讨论过，还是在不同的PEP中？
- Christoph
I''m just reading PEP 3107 (function annotations) and wonder why
exceptions are not mentioned there. I think it would be helpful if one
could specify which exceptions can be raised by a function, similarly to
how it is possible in C++ using the "throw" clause. The syntax would be
something like this:
def foo(a: expr, b: expr = 5) raises expr -expr:
The expr in that "raises" clause should be a list of Exceptions.
Having the list of possible exceptions as annotation alone would be
already helpful. Of course it could be also discussed whether Python
should check that the function really raises only these exceptions (as
in C++), or we could even have checked exceptions (as in Java, but this
seems to be a controversial issue).
Has this already been discussed, or is it in a different PEP?
-- Christoph
请记住，注释只是将一些
信息与参数或功能。有一个名为`return`的特殊
参数，用于帮助将信息与
返回值相关联。该信息是否用于描述函数参数的类型，它们的使用方式或完全不同的东西取决于使用它们的应用程序。
当你说：
Keep in mind that annotations are just a way of associating some
information with the parameters or a function. There is a special
parameter called `return` to help associate information with the
return value. Whether that information is used to describe the types
of the function parameters, how they are used, or something completely
different is up to the application that uses them.
When you say:
expr中的引发子句应该是例外列表。
The expr in that "raises" clause should be a list of Exceptions.
您显然会将注释功能与注释功能的可能
应用混淆。除了类型安全之外，注释可用于许多不同的应用程序。
注释只是创建一个字典。选择名称`return`
作为返回值，因为它_is_是一个关键字，因此不能与任何参数的名称冲突。使用加薪将
意味着我们必须引入名称加注作为新的
关键字。最好只使用它们现有的关键字raise。
说完所有这些，使用
注释的包或应用程序可以只需使用与
" return"相关联的数据结构。还包含异常信息。这可能看起来并不直观，但请记住与返回相关的价值。在
中，协会词典无论如何都将是一个特例。
def foo（a：a info，b：b info ;） - 返回信息，异常信息：
返回hello world
Matt
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.
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".
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"
Matt
Matimus schrieb：
Matimus schrieb:
> expr in theraise子句应该是例外列表。
>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.
注释只是创建一个字典。选择名称`return`
作为返回值，因为它_is_是一个关键字，因此不能与任何参数的名称冲突。使用加薪将
意味着我们必须引入名称加注作为新的
关键字。最好只使用现有关键字raise。
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".
是的，它后来也发现它应该是现有的
关键字，即加注。 （或者可能是除）。这可能是因为它是抛出的原因。
在C ++中，而不是抛出。
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".
说完所有这些，使用
注释的包或应用程序可能只是使用与
return相关联的数据结构还包含异常信息。这可能看起来并不直观，但请记住与返回相关的价值。在
中，协会词典无论如何都将是一个特例。
def foo（a：a info，b：b info ;） - 返回信息，例外信息：
return" hello world"
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"
这是可能的。但是我仍然认为将它们分开来是有意义的，就像这样：
def foo（a：a info，b：" b info"） - " ret info"提高exc info：
返回hello world
然后注释字典将包含另一个键raise
包含exc信息。这也不会与任何其他
参数的名称冲突。
也许以下语法会更直观：
def foo（a：" a info"，b：" b info"）return" ret info"提高兴趣信息：
返回hello world
我不知道如何确定 - >语法已经是。
- Christoph
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
Christoph Zwerschke< ci ** @ online.dewrote：
Christoph Zwerschke <ci**@online.dewrote:
这是可能的。但是我仍然认为将它们分开来是有意义的，就像这样：
def foo（a：a info，b：" b info"） - " ret info"提高exc info：
返回hello world
然后注释字典将包含另一个键raise
包含exc信息。这也不能与任何其他
参数的名称冲突。
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.
如果你真的想要这个，那么你可以使用装饰器插入一个''加注''
键入注释：
@raises（" exc info"）
def foo（ a：a info，b：" b info"） - " ret info"：
return" hello world"
If you really want this then you can use a decorator to insert a ''raise''
key into the annotations:
@raises("exc info")
def foo(a: "a info", b: "b info") -"ret info":
return "hello world"
我不知道如何确定 - >语法已经存在。
I don''t know how determined the "->" syntax is already.
考虑具体设置的语法。
另一只手上的注释的含义完全可以用来获取。
Consider the syntax set in concrete. The meaning of the annotations on the
other hand is completely up for grabs.
这篇关于在PEP 3107中缺少例外的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
