bump to 2.0.7

.github/workflows/validation.yml

@@ -2,6 +2,7 @@ name: 'Validation'
 
 env:
   NODE_VERSION: '16' # Shipped with VS Code.
+  PYTHON_VERSION: 3.11
 
 on:
   push:
@@ -111,6 +112,48 @@ jobs:
         run: npm test
         working-directory: packages/pyright-internal
 
+      # Install python so we can create a VENV for tests
+      - name: Use Python ${{env.PYTHON_VERSION}}
+        uses: actions/setup-python@v4
+        id: install_python
+        with:
+          python-version: ${{env.PYTHON_VERSION}}
+
+      - name: Create Venv
+        run: |
+          ${{ steps.install_python.outputs.python-path }} -m venv .venv
+
+      - name: Activate and install pytest (linux)
+        if: runner.os != 'Windows'
+        run: |
+          source .venv/bin/activate
+          python -m pip install pytest
+          python -c "import sys;print('python_venv_path=' + sys.executable)" >> $GITHUB_ENV
+
+      - name: Activate and install pytest (windows)
+        if: runner.os == 'Windows'
+        run: |
+          .venv\scripts\activate
+          python -m pip install pytest
+          python -c "import sys;print('python_venv_path=' + sys.executable)" | Out-File -FilePath $env:GITHUB_ENV -Append
+
+      - name: Echo python_venv_path
+        run: |
+          echo python_venv_path=${{env.python_venv_path}}
+
+      - name: Run import tests with venv
+        env:
+          CI_IMPORT_TEST_VENVPATH: '../../'
+          CI_IMPORT_TEST_VENV: '.venv'
+        run: npm run test:imports
+        working-directory: packages/pyright-internal
+
+      - name: Run import tests with pythonpath
+        env:
+          CI_IMPORT_TEST_PYTHONPATH: ${{env.python_venv_path}}
+        run: npm run test:imports
+        working-directory: packages/pyright-internal
+
   build:
     runs-on: ubuntu-latest
     name: Build

.gitignore

@@ -122,4 +122,7 @@ junit.xml
 
 # OS files
 .DS_Store
-Thumbs.db
+Thumbs.db
+
+# Potential venv
+.venv

docs/configuration.md

@@ -58,7 +58,9 @@ The following settings control pyright’s diagnostic output (warnings or errors
 
 <a name="deprecateTypingAliases"></a> **deprecateTypingAliases** [boolean]: PEP 585 indicates that aliases to types in standard collections that were introduced solely to support generics are deprecated as of Python 3.9. This switch controls whether these are treated as deprecated. This applies only when pythonVersion is 3.9 or newer. The default value for this setting is `false` but may be switched to `true` in the future.
 
-<a name="enableExperimentalFeatures"></a> **enableExperimentalFeatures** [boolean]: Enables a set of experimental (mostly undocumented) features that correspond to proposed or exploratory changes to the Python typing standard. These features will likely change or be removed, so they should not be used except for experimentation purposes.
+<a name="enableExperimentalFeatures"></a> **enableExperimentalFeatures** [boolean]: Enables a set of experimental (mostly undocumented) features that correspond to proposed or exploratory changes to the Python typing standard. These features will likely change or be removed, so they should not be used except for experimentation purposes. The default value for this setting is `false`.
+
+<a name="disableBytesTypePromotions"></a> **disableBytesTypePromotions** [boolean]: Disables legacy behavior where `bytearray` and `memoryview` are considered subtypes of `bytes`. [PEP 688](https://peps.python.org/pep-0688/#no-special-meaning-for-bytes) deprecates this behavior, but this switch is provided to restore the older behavior. The default value for this setting is `false`.
 
 <a name="reportGeneralTypeIssues"></a> **reportGeneralTypeIssues** [boolean or string, optional]: Generate or suppress diagnostics for general type inconsistencies, unsupported operations, argument/parameter mismatches, etc. This covers all of the basic type-checking rules not covered by other rules. It does not include syntax errors. The default value for this setting is `"error"`.
 
@@ -184,7 +186,7 @@ The following settings control pyright’s diagnostic output (warnings or errors
 
 <a name="reportMatchNotExhaustive"></a> **reportMatchNotExhaustive** [boolean or string, optional]: Generate or suppress diagnostics for a `match` statement that does not provide cases that exhaustively match against all potential types of the target expression. The default value for this setting is `"none"`.
 
-<a name="reportImplicitOverride"></a> **reportImplicitOverride** [boolean or string, optional]: Generate or suppress diagnostics for overridden methods in a class that are missing an explicit `@override` decorator.
+<a name="reportImplicitOverride"></a> **reportImplicitOverride** [boolean or string, optional]: Generate or suppress diagnostics for overridden methods in a class that are missing an explicit `@override` decorator. The default value for this setting is `"none"`.
 
 <a name="reportShadowedImports"></a> **reportShadowedImports** [boolean or string, optional]: Generate or suppress diagnostics for files that are overriding a module in the stdlib. The default value for this setting is `"none"`.
 
@@ -303,6 +305,7 @@ The following table lists the default severity levels for each diagnostic rule w
 | analyzeUnannotatedFunctions               | true       | true       | true       |
 | strictParameterNoneValue                  | true       | true       | true       |
 | enableTypeIgnoreComments                  | true       | true       | true       |
+| disableBytesTypePromotions                | false      | false      | true       |
 | strictListInference                       | false      | false      | true       |
 | strictDictionaryInference                 | false      | false      | true       |
 | strictSetInference                        | false      | false      | true       |

docs/features.md

@@ -34,7 +34,9 @@ Pyright supports [configuration files](configuration.md) that provide granular c
 * [PEP 696](https://www.python.org/dev/peps/pep-0696/) (draft) type defaults for TypeVarLikes
 * [PEP 698](https://www.python.org/dev/peps/pep-0698/) override decorator for static typing
 * [PEP 702](https://www.python.org/dev/peps/pep-0702/) (draft) marking deprecations
+* [PEP 705](https://www.python.org/dev/peps/pep-0705/) (draft) TypedDict: read-only items
 * [PEP 712](https://www.python.org/dev/peps/pep-0712/) (draft) converter parameter on dataclasses.field
+* [PEP 724](https://www.python.org/dev/peps/pep-0724/) (draft) stricter type guards
 * Type inference for function return values, instance variables, class variables, and globals
 * Type guards that understand conditional code flow constructs like if/else statements
 

docs/import-resolution.md

@@ -41,19 +41,9 @@ Pyright uses the following mechanisms (in priority order) to determine which Pyt
 
 ### Editable installs
 
-[PEP 660](https://peps.python.org/pep-0660/) enables build backends (e.g. setuptools) to
-use import hooks to direct the [import machinery](https://docs.python.org/3/reference/import.html)
-to the package’s source files rather than using a `.pth` file. Import hooks can provide
-an editable installation that is a more accurate representation of your real installation.
-However, because resolving module locations using an import hook requires executing Python
-code, they are not usable by Pyright and other static analysis tools. Therefore, if your
-editable install is configured to use import hooks, Pyright will be unable to find the
-corresponding source files.
-
-If you want to use static analysis tools with an editable install, you should configure
-the editable install to use `.pth` files instead of import hooks. See your build backend’s
-documentation for details on how to do this. We have provided some basic information for
-common build backends below.
+[PEP 660](https://peps.python.org/pep-0660/) enables build backends (e.g. setuptools) to use import hooks to direct the [import machinery](https://docs.python.org/3/reference/import.html) to the package’s source files rather than putting the path to those files in a `.pth` file. Import hooks can provide an editable installation that is a more accurate representation of your real installation. However, because resolving module locations using an import hook requires executing Python code, they are not usable by Pyright and other static analysis tools. Therefore, if your editable install is configured to use import hooks, Pyright will be unable to find the corresponding source files.
+
+If you want to use static analysis tools with an editable install, you should configure the editable install to use `.pth` files that contain file paths rather than executable lines (prefixed with `import`) that install import hooks. See your build backend’s documentation for details on how to do this. We have provided some basic information for common build backends below.
 
 #### Setuptools
 Setuptools currently supports two ways to request:

docs/mypy-comparison.md

@@ -152,7 +152,6 @@ Pyright supports several built-in type guards that mypy does not currently suppo
 
 The following expression forms are not currently supported by mypy as type guards:
 * `x == L` and `x != L` (where L is an expression with a literal type)
-* `len(x) == L` and `len(x) != L` (where x is tuple and L is a literal integer)
 * `x in y` or `x not in y` (where y is instance of list, set, frozenset, deque, tuple, dict, defaultdict, or OrderedDict)
 * `bool(x)` (where x is any expression that is statically verifiable to be truthy or falsey in all cases)
 

docs/settings.md

@@ -18,8 +18,14 @@ The Pyright language server honors the following settings.
 
 **python.analysis.diagnosticSeverityOverrides** [map]: Allows a user to override the severity levels for individual diagnostic rules. "reportXXX" rules in the type check diagnostics settings in [configuration](configuration.md#type-check-diagnostics-settings) are supported. Use the rule name as a key and one of "error," "warning," "information," "true," "false," or "none" as value.
 
+**python.analysis.exclude** [array of paths]: Paths of directories or files that should not be included. This can be overridden in the configuration file.
+
 **python.analysis.extraPaths** [array of paths]: Paths to add to the default execution environment extra paths if there are no execution environments defined in the config file.
 
+**python.analysis.ignore** [array of paths]: Paths of directories or files whose diagnostic output (errors and warnings) should be suppressed. This can be overridden in the configuration file.
+
+**python.analysis.include** [array of paths]: Paths of directories or files that should be included. This can be overridden in the configuration file.
+
 **python.analysis.logLevel** ["Error", "Warning", "Information", or "Trace"]: Level of logging for Output panel. The default value for this option is "Information".
 
 **python.analysis.stubPath** [path]: Path to directory containing custom type stub files.

docs/type-concepts-advanced.md

@@ -71,7 +71,7 @@ In addition to assignment-based type narrowing, Pyright supports the following t
 * `x[I] == V` and `x[I] != V` (where I and V are literal expressions and x is a known-length tuple that is distinguished by the index indicated by I)
 * `x[I] is B` and `x[I] is not B` (where I is a literal expression, B is a `bool` or enum literal, and x is a known-length tuple that is distinguished by the index indicated by I)
 * `x[I] is None` and `x[I] is not None` (where I is a literal expression and x is a known-length tuple that is distinguished by the index indicated by I)
-* `len(x) == L` and `len(x) != L` (where x is tuple and L is a literal integer)
+* `len(x) == L` and `len(x) != L` (where x is tuple and L is an expression that evaluates to an int literal type)
 * `x in y` or `x not in y` (where y is instance of list, set, frozenset, deque, tuple, dict, defaultdict, or OrderedDict)
 * `S in D` and `S not in D` (where S is a string literal and D is a TypedDict)
 * `isinstance(x, T)` (where T is a type or a tuple of types)
@@ -319,7 +319,7 @@ Some functions or methods can return one of several different types. In cases wh
 
 [PEP 484](https://www.python.org/dev/peps/pep-0484/#function-method-overloading) introduced the `@overload` decorator and described how it can be used, but the PEP did not specify precisely how a type checker should choose the “best” overload. Pyright uses the following rules.
 
-1. Pyright first filters the list of overloads based on simple “arity” (number of arguments) and keyword argument matching. For example, if one overload requires two position arguments but only one positional argument is supplied by the caller, that overload is eliminated from consideration. Likewise, if the call includes a keyword argument but no corresponding parameter is included in the overload, it is eliminated from consideration.
+1. Pyright first filters the list of overloads based on simple “arity” (number of arguments) and keyword argument matching. For example, if one overload requires two positional arguments but only one positional argument is supplied by the caller, that overload is eliminated from consideration. Likewise, if the call includes a keyword argument but no corresponding parameter is included in the overload, it is eliminated from consideration.
 
 2. Pyright next considers the types of the arguments and compares them to the declared types of the corresponding parameters. If the types do not match for a given overload, that overload is eliminated from consideration. Bidirectional type inference is used to determine the types of the argument expressions.
 
@@ -329,7 +329,7 @@ Some functions or methods can return one of several different types. In cases wh
     Exception 1: When an `*args` (unpacked) argument matches a `*args` parameter in one of the overload signatures, this overrides the normal order-based rule.
     Exception 2: When two or more overloads match because an argument evaluates to `Any` or `Unknown`, the matching overload is ambiguous. In this case, pyright examines the return types of the remaining overloads and eliminates types that are duplicates or are subsumed by (i.e. proper subtypes of) other types in the list. If only one type remains after this coalescing step, that type is used. If more than one type remains after this coalescing step, the type of the call expression evaluates to `Unknown`. For example, if two overloads are matched due to an argument that evaluates to `Any`, and those two overloads have return types of `str` and `LiteralString`, pyright will coalesce this to just `str` because `LiteralString` is a proper subtype of `str`. If the two overloads have return types of `str` and `bytes`, the call expression will evaluate to `Unknown` because `str` and `bytes` have no overlap.
 
-5. If no overloads remain, Pyright considers whether any of the arguments are union types. If so, these union types are expanded into their constituent subtypes, and the entire process of overload matching is repeated with the expanded argument types. If two or more overloads match, the union of their respective return types form the final return type for the call expression.
+5. If no overloads remain, Pyright considers whether any of the arguments are union types. If so, these union types are expanded into their constituent subtypes, and the entire process of overload matching is repeated with the expanded argument types. If two or more overloads match, the union of their respective return types form the final return type for the call expression. This "union expansion" can result in a combinatoric explosion if many arguments evaluate to union types. For example, if four arguments are present, and they all evaluate to unions that expand to ten subtypes, this could result in 10^4 combinations. Pyright expands unions for arguments left to right and halts expansion when the number of signatures exceeds 64.
 
 6. If no overloads remain and all unions have been expanded, a diagnostic is generated indicating that the supplied arguments are incompatible with all overload signatures.
 

lerna.json

@@ -2,7 +2,7 @@
     "packages": [
         "packages/*"
     ],
-    "version": "1.1.328",
+    "version": "1.1.334",
     "command": {
         "version": {
             "push": false,