有几种方法可以禁用Pylint中的警告和错误。使用哪一个与您希望如何全局或局部地应用禁用有关——这是一个重要的设计决策。
多种方法
在一个或多个pylintrc文件中。
这不仅仅涉及到~/。pylintrc文件(在$HOME目录下),如Chris Morgan所述。Pylint将搜索rc文件,优先级为“更接近”的文件:
当前工作目录中的pylintrc文件;或
如果当前工作目录在Python模块中(即它包含__init__.py文件),则向上搜索Python模块的层次结构,直到找到pylintrc文件;或
由环境变量PYLINTRC命名的文件;或
如果你的主目录不是/root:
~ / .pylintrc;或
~ / config / pylintrc;或
/etc/pylintrc
注意,这些文件中的大多数都被命名为pylintrc——只有~中的文件有一个前导点。
在pylintrc文件中,添加禁用特定pylint消息的行。例如:
[MESSAGES CONTROL]
disable=locally-disabled
Further disables from the pylint command line, as described by Aboo and Cairnarvon. This looks like pylint --disable=bad-builtin. Repeat --disable to suppress additional items.
Further disables from individual Python code lines, as described by Imolit. These look like some statement # pylint: disable=broad-except (extra comment on the end of the original source line) and apply only to the current line. My approach is to always put these on the end of other lines of code so they won't be confused with the block style, see below.
Further disables defined for larger blocks of Python code, up to complete source files.
These look like # pragma pylint: disable=bad-whitespace (note the pragma key word).
These apply to every line after the pragma. Putting a block of these at the top of a file makes the suppressions apply to the whole file. Putting the same block lower in the file makes them apply only to lines following the block. My approach is to always put these on a line of their own so they won't be confused with the single-line style, see above.
When a suppression should only apply within a span of code, use # pragma pylint: enable=bad-whitespace (now using enable not disable) to stop suppressing.
注意,禁用一行使用# pylint语法,而禁用这一行使用# pragma pylint语法。这些很容易混淆,特别是在复制和粘贴时。
把它们放在一起
我通常混合使用这些方法。
I use ~/.pylintrc for absolutely global standards -- very few of these.
I use project-level pylintrc at different levels within Python modules when there are project-specific standards. Especially when you're taking in code from another person or team, you may find they use conventions that you don't prefer, but you don't want to rework the code. Keeping the settings at this level helps not spread those practices to other projects.
I use the block style pragmas at the top of single source files. I like to turn the pragmas off (stop suppressing messages) in the heat of development even for Pylint standards I don't agree with (like "too few public methods" -- I always get that warning on custom Exception classes) -- but it's helpful to see more / maybe all Pylint messages while you're developing. That way you can find the cases you want to address with single-line pragmas (see below), or just add comments for the next developer to explain why that warning is OK in this case.
I leave some of the block-style pragmas enabled even when the code is ready to check in. I try to use few of those, but when it makes sense for the module, it's OK to do as documentation. However I try to leave as few on as possible, preferably none.
I use the single-line-comment style to address especially potent errors. For example, if there's a place where it actually makes sense to do except Exception as exc, I put the # pylint: disable=broad-except on that line instead of a more global approach because this is a strange exception and needs to be called out, basically as a form of documentation.
像Python中的其他东西一样,您可以在不同的间接级别上进行操作。我的建议是,考虑一下哪些内容属于哪个级别,这样就不会对Pylint采取过于宽松的方法。