pylint W0212-therning在执行Unitests时

发布于 2025-01-18 12:26:28 字数 1683 浏览 3 评论 0 原文

我们经常将此双重下建议的前缀用于我们的课程的内部方法。这通常在单位测试过程中升高W0212,因为我们将Protcted方法直接称为EG testClass().__ my_private_method()

我知道在Python中没有私人方法。尽管如此,由于结构原因,我发现使用强调前缀有益的做法,例如,对于其他开发人员来说,它很明显。

现在,我从

class Foo:
    def __bar(self):
        pass

    def baz(self):
        return self.__bar()


foo = Foo()
foo.baz()

基于此,您可以在不禁用这样的W0212的情况下创建一种方法:

class SomeClass:
    """ some docstring
    """
    def __init__(self) -> None:
        self.myattr = 1

    def __my_protected_method(self):
        return self.myattr + 1

    def __another_protected_method(self):
        return self.myattr + 2

    def method_for_unittests(self, method_name):
        if method_name == "my_protected_method":
            return self.__my_protected_method()
        if method_name == "another_protected_method":
            return self.__another_protected_method()
        return None

这似乎是一个更好的解决方案,而不是使用单独的 .pypy> .pylintrc (建议在这里)。这就提出了以下问题:

  1. 我的解决方案是否有意义,或者我们应该坚持 #pylint:disable = preected-access
  2. 还是使用特殊装饰器有更好的解决方案?我看到了一些东西在这里 ,这让我很好奇。我几乎没有写作者的经验,因此相对天真的问题。

we often use this double underscore prefix for internal methods of our classes. This usually raises a W0212 during unit-testing, because we call the proctected methods directly e.g. TestClass().__my_private_method().

I know that in Python there are no private methods. Nevertheless I find this practice of using the underscore prefix good for structural reasons, e.g., it makes it quite obvious to other developers how to use a class.

Now I found this fix for the W0212-Warning from the phoenix-github-page:

class Foo:
    def __bar(self):
        pass

    def baz(self):
        return self.__bar()


foo = Foo()
foo.baz()

Based on this you could create a method for unittest without disabling W0212 like this:

class SomeClass:
    """ some docstring
    """
    def __init__(self) -> None:
        self.myattr = 1

    def __my_protected_method(self):
        return self.myattr + 1

    def __another_protected_method(self):
        return self.myattr + 2

    def method_for_unittests(self, method_name):
        if method_name == "my_protected_method":
            return self.__my_protected_method()
        if method_name == "another_protected_method":
            return self.__another_protected_method()
        return None

This seems like a nicer solution than using a seperate .pylintrc (suggested here). This begs the following questions:

  1. Does my solution make sense or should we just stick with #pylint: disable=protected-access?
  2. Or do you maybe have a better solution using a special decorator? I saw something here, which made me curious. I have little experience writing decorators, therefore the comparatively naive question.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(1

离不开的别离 2025-01-25 12:26:28

使用 pylint 总是可以禁用该消息,或者通过 hack 使其消失。但最好是简单地禁用消息,而不是破解一些能让 pylint 停止抱怨的东西(但不会让代码变得更好)。最好的办法是了解根本问题并解决它。

如果您正在创建一个仅用于测试的函数(仅用于测试的 API),那么您就是在进行黑客攻击,让 pylint 认为您正在使用公共 API。相反,您应该做的是通过函数的公共接口(通过到处使用的真实 API)测试私有/受保护的方法,正如 @jonrscharpe 在评论中指出的那样。

如果您不能这样做,则意味着私有类隐藏在您的代码中等待创建。

广告:我们正在尝试纳入并改进您在问题中链接到 pylint 的 valid-phoenix 的文档工作。您可以帮助 pylint 团队提出更好的修复建议,请参阅 https://github.com/PyCQA /pylint/issues/5953

With pylint it's always possible to disable the message, or to make it disappear by using a hack. But it's better to simply disable messages than to hack something that will make pylint stop complaining (but won't make the code better). The best thing to do is to understand the underlying issue to fix it.

If you're creating a function that will be used only for tests (a test only API) you're doing a hack to make pylint think you're using a public API. What you should do instead is to test private/protected methods through the public interface of your function (through the real API used everywhere) as pointed out by @jonrscharpe in comment.

If you can't do that, then it means that a private class is hiding inside your code waiting to be created.

Advertisement: We're trying to include and improve the documentation work of valid-phoenix that you linked in the question into pylint. You can help the pylint team make better suggestions of fixes, see https://github.com/PyCQA/pylint/issues/5953

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文