Python：在函数属性中存储预期的异常

Question

将函数的预期异常存储为函数本身的属性是pythonic吗？或者只是一个糟糕的坏习惯。你知道吗

像这样的

class MyCoolError(Exception):
    pass

def function(*args):
    """
    :raises: MyCoolError

    """
    # do something here
    if some_condition:
        raise MyCoolError

function.MyCoolError = MyCoolError

在另一个模块里

try:
    function(...)
except function.MyCoolError:
    #...

Pro:只要有对函数的引用，就有对它可能引发的异常的引用，而不必显式导入它。你知道吗

Con:我“必须”重复异常的名称以将其绑定到函数。这可以通过一个装饰器来完成，但也增加了复杂性。你知道吗

编辑

我之所以这样做是因为我以一种不规则的方式将一些方法附加到一些类中，我认为在这些类中混用是不值得的。我们称之为“定制的附加功能”。比如说：

• Class A使用方法fn1和fn2
• Class B使用方法fn2和fn3
• Class C使用fn4。。。你知道吗
• 像这样大约15节课。你知道吗

因此，当我调用obj_a.fn2()时，我必须显式导入它可能引发的异常（它不在类A、B或C所在的模块中，而是在共享方法所在的另一个模块中）。。。我觉得有点烦。很明显，我正在使用的项目中的标准样式强制每行编写一个导入，因此它变得非常冗长。你知道吗

在一些代码中，我看到异常存储为类属性，我发现它非常有用，例如：

try:
    obj.fn()
except obj.MyCoolError:
    ....

Answer 1

我认为这不是Python。我还认为，与标准方法相比，它没有提供太多的优势，标准方法应该是将异常与函数一起导入。你知道吗

Python程序使用import语句来说明代码的来源是有原因的（除了帮助解释器之外）；它有助于找到您正在使用的工具的代码（例如，本例中的异常）。你知道吗

整个想法都有异常声明的味道，因为它在C++中是可能的，在java中是部分强制的。语言律师们正在讨论这是一个好主意还是一个坏主意，在Python的世界里，设计者们决定反对它，所以它不是Pythonic。你知道吗

这也提出了一大堆进一步的问题。如果您的函数A正在使用另一个函数B，那么会发生什么情况？该函数B稍后会被更改，以便它可以抛出异常（在Python中是有效的）。你是否愿意改变你的函数来反映这一点？您想在哪里画一条线-使用int(text)将字符串转换为int reason足以“声明”可以抛出ValueError？你知道吗

总而言之，我认为这不是Python，不是