heyas, I'm working on helpers for lockfiles, tryin...
# development
c
heyas, I'm working on helpers for lockfiles, trying to reduce the small differences between some of the tools. The Mypy and Black plugins are slightly different from the others (flake8, pylint, basically everything else): They skip checking the code's interpreter constraints if a nondefault value is specified for
interpreter_constraints
(link). This is distinct from the similar (?) check done in the
PythonToolBase
(link) (link to issue discussing this) Questions: Is it still necessary to do this check in lockfile generation? What effect does this actually have, given the additional check? Should the other tools do this check as well?
h
@hundreds-father-404 is the expert, but I think this has to do with the fact that those tools actually behave differently depending on the target python version?
h
So MyPy and Black are tricky because they use the library
typed-ast
to understand different versions of Python than the Python interpreter being used. A neat feature of
typed-ast
is it let you understand both older and newer versions of the current interpreter Unfortuantely, typed-ast stopped being updated because the std-lib gained this functionality. Except, the std-lib only can look backwards, as it doesn't know the syntax of future Python versions. This means that when you run Black with Python 3.8, it can't understand Python 3.9+ syntax. So, instead, you need to run the tool with 3.9+ Pants gets clever to try to do the right thing for users automatically. We detect if your code is 3.8+ (where typed-ast stopped working), and if so, use your code's constraints rather than tool constraints; but only if you didn't explicitly set the tool's option
c
Oh ok, that's interesting. Maybe a silly question, could we not just always use the code's constraints? I guess if someone had python2 code, we'd like to still run with Black from python3.7?
h
Exactly
👍 1