Prepare release 0.11.0

docs/annotated_types.md

@@ -38,6 +38,9 @@ def caller(i: int) -> None:
         takes_gt_5(i)  # accepted
 ```
 
+Similarly, pyanalyze infers the `MinLen` and `MaxLen` attributes after checks
+on `len()`.
+
 For the `MultipleOf` check, pyanalyze follows Python semantics: values
 are accepted if `value % multiple_of == 0`.
 

docs/changelog.md

@@ -1,8 +1,9 @@
 # Changelog
 
-## Unreleased
+## Version 0.11.0 (October 3, 2023)
 
-- Partial support for PEP 695-style type aliases (#690, #692)
+- Partial support for PEP 695-style type aliases. Scoping changes
+  are not yet fully implemented. (#690, #692)
 - Fix tests to account for new `typeshed_client` release
   (#694)
 - Add option to disable all error codes (#659)

docs/typesystem.md

@@ -295,6 +295,7 @@ Although pyanalyze aims to support the full Python type system, support for some
 - Variance of TypeVars
 - `NewType` over non-trivial types
 - `ParamSpec` (PEP 612)
+- `TypeVarTuple` (PEP 646)
 
 More generally, Python is sufficiently dynamic that almost any check like the ones run by pyanalyze will inevitably have false positives: cases where the script sees an error, but the code in fact runs fine. Attributes may be added at runtime in hard-to-detect ways, variables may be created by direct manipulation of the `globals()` dictionary, and the `unittest.mock` module can change anything into anything. Although pyanalyze has a number of configuration mechanisms to deal with these false positives, it is usually better to write code in a way that doesn't require use of these knobs: code that's easier for the script to understand is probably also easier for humans to understand.
 

setup.py

@@ -2,7 +2,7 @@
 from setuptools import setup
 
 
-version = "0.10.1"
+version = "0.11.0"
 package_data = ["test.toml", "stubs/*/*.pyi"]