netromdk / vermin

Concurrently detect the minimum Python versions needed to run code

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

#novermin exclusion comment does not work for all rules

gousaiyang opened this issue · comments

Describe the bug

The # novermin exclusion comment does not work for all rules/syntactic structures.

To Reproduce

Taking the code in the README as an example:

In [127]: vermin.detect('''\
     ...: import ssl
     ...: tls_version = ssl.PROTOCOL_TLSv1
     ...: if hasattr(ssl, "PROTOCOL_TLS"):  # novermin
     ...:   tls_version = ssl.PROTOCOL_TLS
     ...: ''')
Out[127]: [(2, 6), (3, 0)]

In [128]: vermin.detect('''\
     ...: import ssl
     ...: tls_version = ssl.PROTOCOL_TLSv1
     ...: if hasattr(ssl, "PROTOCOL_TLS"):
     ...:   tls_version = ssl.PROTOCOL_TLS  # novermin
     ...: ''')
Out[128]: [(2, 7), (3, 6)]

When # novermin is moved to the same line of the code to be excluded, it fails to exclude the code (ssl.PROTOCOL_TLS in this case).

Expected behavior

# novermin should always exclude the code on the same line from analysis (or the next line if # novermin is the only content of a line).

Environment (please complete the following information):

  • Vermin version 1.0.3

Additional context

The problem is that in source_visitor.py, not all visit_* functions call if self.__is_no_line(node.lineno): return on start. Thus visit_Attribute and many other functions are not doing exclusion.

Question: Should syntax-level rules ever be excluded? (Should visit_JoinedStr exclude f'{1+1}' # novermin?)

Thanks for the feedback. It is true that lines are not ignored all places. Currently it will happen for:

  • import
  • if statement
  • if expression
  • for
  • while
  • Functions definitions and function calls (also async)
  • Function and class decorators (but only when there's only one defined)
  • Class definitions
  • try..
  • Boolean operators

But I will add to other things, like assignments etc. Possibly with a decorator to streamline it a bit more.

Question: Should syntax-level rules ever be excluded? (Should visit_JoinedStr exclude f'{1+1}' # novermin?)

Hmm that could make sense but I think I'd prefer to focus on the statement-level abstraction first.

I've pushed additional exclusion support to branch issue_59:

  • with
  • async for
  • raise
  • yield
  • yield from
  • Except handlers
  • Subscripts
  • Named expressions
  • await
  • Assignments
  • Augmented assignments
  • Annotated assignments
  • Function and class decorators (when there are 1+ specified)

Merged to dev branch.