点击和pylint

dod*_*0ro 13 python pylint python-3.x python-click visual-studio-code

以下是导致pylint错误的点击使用的简单示例:

@click.command()
@click.option('--option', is_flag=True)
def foo(option):
    click.echo(option)

foo()
Run Code Online (Sandbox Code Playgroud)

foo没有参数,所以我得到了E1120(没有值参数).所以我这样做了:

@click.command()
@click.option('--option', is_flag=True)
def foo(**kwargs):
    click.echo(kwargs["option"])

foo()
Run Code Online (Sandbox Code Playgroud)

有没有更好的办法?或者在Visual Studio代码中仅禁用一行的pylint的方法?

Azs*_*sgy 16

@click.command装饰编辑你的函数的参数,但pylint的不知道这一点,因为它实际上并没有运行代码.

我觉得让你的代码变得怪异只是因为pylint很高兴是不合理的.相反,忽略它,或添加注释以在当前范围中禁用该警告:

# pylint: disable=no-value-for-parameter
Run Code Online (Sandbox Code Playgroud)

  • 在检查@click-decorated 函数时,有没有办法告诉 pylint _always_ 禁用无值参数?(所以我不必在每个脚本中都这样做。) (3认同)
  • 是的,将此注释添加到行末 (2认同)

xto*_*ofl 9

同时,pylint 作者添加了一种方法来处理这个问题:signature-mutators设置。

这应该告诉 pylint click 会改变函数签名,并且它应该看起来更深入一些:

# .pylintrc
...
signature-mutators=click.decorators.option
Run Code Online (Sandbox Code Playgroud)

pylint检查被调用函数的装饰器的名称/限定名称是否在列表中signature-mutators。因此,我们不能使用click.option,因为这是一个别名,但我们必须使用声明的名称。

为了完整起见,我认为我们可以添加在以下位置找到的所有装饰器click/decorators.py

[TYPECHECK]
signature-mutators=click.decorators.option,
                   click.decorators.argument,
                   click.decorators.version_option,
                   click.decorators.help_option,
                   click.decorators.pass_context,
                   click.decorators.confirmation_option
Run Code Online (Sandbox Code Playgroud)

注意:此设置需要位于该[TYPECHECK]部分下。(谢谢@Federico Corazza)


Pet*_*zuk 6

有一种方法可以通过不使用装饰语法来避免这些错误的发生。这可能就是@Azsgy 所说的“怪异”:-)

@click.option(
    "--direction",
    default="upgrade",
    type=click.Choice(["upgrade", "downgrade"]),
    help="Direction of migration upgrade/downgrade",
)
@click.argument("revision", default="heads")
def _main(direction, revision):
    """Runs migrations on each of the databases."""
    pass


main = click.command()(_main)


if __name__ == "__main__":
    main()
Run Code Online (Sandbox Code Playgroud)

它是否好是值得商榷的:-)