```
In [4]: ast.dump(ast.parse('f"{x!r}"'))
Out[4]: "Module(body=[Expr(value=JoinedStr(values=[FormattedValue(value=Name(id='x', ctx=Load()), conversion=114)]))], type_ignores=[])"
In [5]: ast.dump(ast.parse('f"{x}"'))
Out[5]: "Module(body=[Expr(value=JoinedStr(values=[FormattedValue(value=Name(id='x', ctx=Load()), conversion=-1)]))], type_ignores=[])"
```
(On 3.9 but I don't think this has changed since 3.6.)
The stdlib also assumes this: https://github.com/python/cpython/blob/main/Lib/ast.py#L1211 (`chr(None)` doesn't work).
https://github.com/python/cpython/pull/91997
`description` isn't actually read-only at runtime, but I don't think there's any other way of telling type checkers "this is an attribute that the members have, not a member itself". And pretending it's a property is already what we do for `HTTPStatus`, which has the same issue.
The `fields` arg of `dataclass.make_dataclass` should have type:
```
Iterable[str | tuple[str, type] | tuple[str, type, Any]]
```
Previously the 3-tuple had type `tuple[str, type, Field[Any]]`, which
was incorrect for two reasons:
- The third element in the tuple doesn't have to be a ``Field``, it can
be any RHS value valid when defining a dataclass field (e.g.
``myfield: type = ...``). This may be a ``Field``, but it may also be a
default value like ``0``. ``Any`` is the proper type here.
- The type stubs for ``dataclass.field`` lie and say that this function
returns a value with the same type as ``default``. This avoids the need
for a mypy/pyright plugin that understands dataclasses, but also means
there is no way to create a ``Field`` object that these tools
understand, since they don't think ``dataclasses.field`` returns a
``Field`` instance.
With this change, the following valid dataclasses code passes both mypy
and pyright:
```python
from dataclasses import field, make_dataclass
Point = make_dataclass("Point", [("x", int), ("y", int), ("z", int, 0)])
Point2 = make_dataclass("Point2", [("x", int), ("y", int), ("z", int, field(default=0))])
```
- mypy_test and pyright no longer just test the stubs, they now also test other parts of typeshed as well.
- pytype_test.py can now be run on 3.10, meaning the whole test suite can now also be run on 3.10.
- Various test scripts now have from `__future__ import annotations`, meaning they can now only be run on 3.7+.
- Clean up the description of pyright_test.py, which had a slightly confusing wording.
- Also fix the `--dry-run` config option in mypy_test.py, which I accidentally broke in #7746
This pull request reverts part of #2539 that brought back a bug discussed in https://github.com/python/mypy/issues/5788 and initially fixed in #2539
In short, the issue was that the following program always resulted
in an error when running mypy with the `--disallow-any-expr` flag:
from enum import Enum
class MyEnum(Enum):
FOO = 1
BAR = 2
blah = MyEnum # Error here
The root issue was that because the signature of Enum's
`__new__` method was typed as:
def __new__(self: Type[T], value: Any) -> T: ...
This caused mypy to decide that the type of `MyEnum` was
`(Any) -> MyEnum`. This is correct based on the current
type signature, but unfortunately means that it becomes
impossible to ever use enums with the `--disallow-any-expr` flag.
Fixes#7698.
At runtime, these methods call `tkinter._flatten()`, which recursively turns lists or tuples (but not other sequences) into a flat tuple of items. Unfortunately we don't have recursive types yet.
- Add several type hints to untyped functions.
- While we're at it, upgrade several annotations to use modern syntax by using `from __future__ import annotations`. This means that the tests can't be run on Python 3.6, but 3.6 is EOL, and it is already the case that some scripts in this directory can only be run on more recent Python versions. E.g. `check_new_syntax.py` uses `ast.unparse`, which is only available in Python 3.9+.
- Fix a few pieces of code that didn't type check.
