You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
Support conditional Python version and platform checks #698
Mypy should support some common kinds of Python version checks and platform checks (e.g. Windows vs. Posix). We should ignore code paths that won't be run on the targeted Python version or platform. This way mypy can more effectively type check code that supports Python 2 and 3 and multiplatform code.
We first need to decide which checks to support. These examples are from PEP 484 and should be supported:
importsysifsys.version_info[0] >=3:
# Python 3 specific definitions
...
else:
# Python 2 specific definitions
...
ifsys.platform=='win32':
# Windows specific definitions
...
else:
# Posix specific definitions
...
When type checking code as above, always only if or the else block would be analyzed, never both, since on any given program run only one them can be evaluated (we assume that nobody does anything crazy like modifying sys.platform at runtime). We'd detect the check expressions during semantic analysis and wouldn't semantically analyze (or type check) the skipped blocks, similar to how mypy currently deals with PY2/PY3 conditions in if statements.
We already have Python 2 and Python 3 modes, and we should also implement Windows and non-Windows (Posix) modes. Initially, we can just use the platform on which the type checker is being run, but more generally this should be configurable (e.g., mypy --platform win32 ...).
Cases like the one above could be handled already by defining a type variable or synonym MyStr conditionally on the python version and then declaring the type of quote to be (MyStr) -> MyStr.
Aliases can be a little tricky, as we currently don't process any aliases during the first semantic analysis pass -- and we'd probably want to process version checks during the first pass. A potential approach is to special case the detection of these aliases during the first pass, and ignore assignment statements that don't look like aliases that we are going to support.
As imports aren't fully processed during the first pass, you may want to just add some special cased imported values to the symbol table during the pass -- even having a special, temporary symbol table just for conditional definitions might not be terrible. For example, shallow process import sys and from sys import platform during the first pass without actually looking at the sys stub file, but skip other imports.
Importing conditional flags from other modules may also be a little tricky (for example, from myappconfig import PY3 or similar). Perhaps we don't need to support these initially.
Simple Python version checks without aliases are probably the most important use case (for python 2 and 3 compatible stubs), and focusing on this first seems reasonable.
Good to know. Are there any existing helper functions that might be useful
to pick apart things like tuples of int literals or e.g.
sys.version_info[:2]? (I'm not afraid to hand-code these, but if something
relevant already exists I'd like to use it.)
I did the first two bullets of my plan, and filed separate issues for the last two (the last one I think we may not actually need). So I'm closing this.
Activity
JukkaL commentedon May 31, 2015
We should also support code that assigns the result of a check to a variable. Example:
methane commentedon May 18, 2016
How about type comment?
or
gvanrossum commentedon May 18, 2016
Please no new proposals.
rwbarton commentedon May 18, 2016
Cases like the one above could be handled already by defining a type variable or synonym
MyStrconditionally on the python version and then declaring the type ofquoteto be(MyStr) -> MyStr.methane commentedon May 18, 2016
I'm sorry, and thanks for information.
gvanrossum commentedon Jul 5, 2016
Note that different versions may have different signatures for the same function. This should definitely be supported.
gvanrossum commentedon Jul 26, 2016
My plan:
I may need help with the last item, and maybe we should update PEP 484 to clarify what's allowed.
JukkaL commentedon Jul 26, 2016
Here are some thoughts:
import sysandfrom sys import platformduring the first pass without actually looking at thesysstub file, but skip other imports.from myappconfig import PY3or similar). Perhaps we don't need to support these initially.gvanrossum commentedon Jul 26, 2016
JukkaL commentedon Jul 26, 2016
There's
visit_tuple_slice_helperincheckexpr.pywhich might be relevant.Implement most common sys.version_info and sys.platform checks (#1942)
gvanrossum commentedon Aug 5, 2016
I did the first two bullets of my plan, and filed separate issues for the last two (the last one I think we may not actually need). So I'm closing this.