fixup! feat: add ty

Author: SimonSchick

conformance/README.md

@@ -10,26 +10,26 @@ Accompanying the typing specification is this conformance test suite which valid
 
 This project contains test cases for behaviors defined in the Python typing spec. Tests are structured and grouped in accordance with the specification's chapter headings.
 
-- [concepts](https://typing.python.org/en/latest/spec/concepts.html)
-- [annotations](https://typing.python.org/en/latest/spec/annotations.html)
-- [specialtypes](https://typing.python.org/en/latest/spec/special-types.html)
-- [generics](https://typing.python.org/en/latest/spec/generics.html)
-- [qualifiers](https://typing.python.org/en/latest/spec/qualifiers.html)
-- [classes](https://typing.python.org/en/latest/spec/class-compat.html)
-- [aliases](https://typing.python.org/en/latest/spec/aliases.html)
-- [literals](https://typing.python.org/en/latest/spec/literal.html)
-- [protocols](https://typing.python.org/en/latest/spec/protocol.html)
-- [callables](https://typing.python.org/en/latest/spec/callables.html)
-- [constructors](https://typing.python.org/en/latest/spec/constructors.html)
-- [overloads](https://typing.python.org/en/latest/spec/overload.html)
-- [dataclasses](https://typing.python.org/en/latest/spec/dataclasses.html)
-- [typeddicts](https://typing.python.org/en/latest/spec/typeddict.html)
-- [tuples](https://typing.python.org/en/latest/spec/tuples.html)
-- [namedtuples](https://typing.python.org/en/latest/spec/namedtuples.html)
-- [narrowing](https://typing.python.org/en/latest/spec/narrowing.html)
-- [directives](https://typing.python.org/en/latest/spec/directives.html)
-- [distribution](https://typing.python.org/en/latest/spec/distributing.html)
-- [historical](https://typing.python.org/en/latest/spec/historical.html)
+* [concepts](https://typing.python.org/en/latest/spec/concepts.html)
+* [annotations](https://typing.python.org/en/latest/spec/annotations.html)
+* [specialtypes](https://typing.python.org/en/latest/spec/special-types.html)
+* [generics](https://typing.python.org/en/latest/spec/generics.html)
+* [qualifiers](https://typing.python.org/en/latest/spec/qualifiers.html)
+* [classes](https://typing.python.org/en/latest/spec/class-compat.html)
+* [aliases](https://typing.python.org/en/latest/spec/aliases.html)
+* [literals](https://typing.python.org/en/latest/spec/literal.html)
+* [protocols](https://typing.python.org/en/latest/spec/protocol.html)
+* [callables](https://typing.python.org/en/latest/spec/callables.html)
+* [constructors](https://typing.python.org/en/latest/spec/constructors.html)
+* [overloads](https://typing.python.org/en/latest/spec/overload.html)
+* [dataclasses](https://typing.python.org/en/latest/spec/dataclasses.html)
+* [typeddicts](https://typing.python.org/en/latest/spec/typeddict.html)
+* [tuples](https://typing.python.org/en/latest/spec/tuples.html)
+* [namedtuples](https://typing.python.org/en/latest/spec/namedtuples.html)
+* [narrowing](https://typing.python.org/en/latest/spec/narrowing.html)
+* [directives](https://typing.python.org/en/latest/spec/directives.html)
+* [distribution](https://typing.python.org/en/latest/spec/distributing.html)
+* [historical](https://typing.python.org/en/latest/spec/historical.html)
 
 A test file is a ".py" file. The file name should start with one of the above names followed by a description of the test (with words separated by underscores). For example, `generics_paramspec_basic_usage.py` would contain the basic usage tests for `ParamSpec`. Each test file can contain multiple individual unit tests, but these tests should be related to each other. If the number of unit tests in a single test file exceeds ten, it may be desirable to split it into separate test files. This will help maintain a consistent level of granularity across tests.
 
@@ -43,37 +43,36 @@ The test suite focuses on static type checking not general Python semantics. Tes
 
 Test cases use the following conventions:
 
-- Lines that are expected to produce a type checker error should have a comment starting with # E",
+* Lines that are expected to produce a type checker error should have a comment starting with # E",
   either by itself or followed by an explanation after a colon (e.g., "# E: int is not a subtype
   of str"). Such explanatory comments are purely for human understanding, but type checkers are not
   expected to use their exact wording. There are several syntactic variations; see "Test Case Syntax"
   below.
-- Lines that may produce an error (e.g., because the spec allows multiple behaviors) should be
+* Lines that may produce an error (e.g., because the spec allows multiple behaviors) should be
   marked with "# E?" instead of "# E".
-- If a test case tests conformance with a specific passage in the spec, that passage should be
+* If a test case tests conformance with a specific passage in the spec, that passage should be
   quoted in a comment prefixed with "# > ".
 
 ## Test Case Syntax
 
 Test cases support the following special comments for declaring where errors should be raised:
 
-- `# E`: an error must be raised on this line
-- `# E?`: an error may be raised on this line
-- `# E[tag]`, where `tag` is an arbitrary string: must appear multiple times in a file with the same tag.
+* `# E`: an error must be raised on this line
+* `# E?`: an error may be raised on this line
+* `# E[tag]`, where `tag` is an arbitrary string: must appear multiple times in a file with the same tag.
   Exactly one line with this tag must raise an error.
-- `# E[tag+]`: like `# E[tag]`, but errors may be raised on multiple lines.
+* `# E[tag+]`: like `# E[tag]`, but errors may be raised on multiple lines.
 
 Each comment may be followed by a colon plus an explanation of the error; the explanation is ignored
 by the scoring system.
 
 ## Running the Conformance Test Tool
 
 To run the conformance test suite:
-
-- Clone the https://github.com/python/typing repo.
-- Create and activate a Python 3.12 virtual environment.
-- Switch to the `conformance` subdirectory and install all dependencies (`pip install -r requirements.txt`).
-- Switch to the `src` subdirectory and run `python main.py`.
+* Clone the https://github.com/python/typing repo.
+* Create and activate a Python 3.12 virtual environment.
+* Switch to the `conformance` subdirectory and install all dependencies (`pip install -r requirements.txt`).
+* Switch to the `src` subdirectory and run `python main.py`.
 
 Note that some type checkers may not run on some platforms. If a type checker fails to install, tests will be skipped for that type checker.
 
@@ -99,16 +98,16 @@ If a new version of a type checker is released, re-run the test tool with the ne
 
 In addition to manual scoring, we provide an experimental tool that automatically checks type checkers for conformance. This tool relies on the "# E" comments present in the stubs and on parsing type checker output. This logic is run automatically as part of the conformance test tool. It produces the following fields in the `.toml` output files:
 
-- `errors_diff`: a string describing all issues found with the type checker's behavior: either expected errors that were not emitted, or extra errors that the conformance test suite does not allow.
-- `conformance_automated`: either "Pass" or "Fail" based on whether there are any discrepancies with the expected behavior.
+* `errors_diff`: a string describing all issues found with the type checker's behavior: either expected errors that were not emitted, or extra errors that the conformance test suite does not allow.
+* `conformance_automated`: either "Pass" or "Fail" based on whether there are any discrepancies with the expected behavior.
 
 This tool does not yet work reliably on all test cases. The script `conformance/src/unexpected_fails.py` can be run to find all test cases where the automated tool's conformance judgment differs from the manual judgment entered in the `.toml` files.
 
 Some common problems with automated checks:
 
-- Sometimes the spec is imprecise or allows multiple options. In this case, use "# E?" to mark an error as optional.
-- Type checkers may produce additional errors for issues unrelated to the topic being tested. In this case, add an extra field `ignore_errors` in the type checker's `.toml` file that contains the text of the irrelevant errors. Any error message that contains a substring in the `ignore_errors` list is ignored. For example, if `ignore_errors = ["Too many arguments"]`, then a mypy error `dataclasses_usage.py:127: error: Too many arguments for "DC7"  [call-arg]` will be ignored.
-- Type checkers may differ in the line on which they report an error. In this case, on each of the lines where an error could
+* Sometimes the spec is imprecise or allows multiple options. In this case, use "# E?" to mark an error as optional.
+* Type checkers may produce additional errors for issues unrelated to the topic being tested. In this case, add an extra field `ignore_errors` in the type checker's `.toml` file that contains the text of the irrelevant errors. Any error message that contains a substring in the `ignore_errors` list is ignored. For example, if `ignore_errors = ["Too many arguments"]`, then a mypy error `dataclasses_usage.py:127: error: Too many arguments for "DC7"  [call-arg]` will be ignored.
+* Type checkers may differ in the line on which they report an error. In this case, on each of the lines where an error could
   reasonably be shown, write `# E[<tag>]`, where `<tag>` is an arbitrary string that is unique in the file. The test will be marked as passing if the type checker produces an error on exactly one of the lines where this tag appears.
 
 ## Contributing