Although the specific format of the bytes is opaque and undocumented, the fact that it will be bytes is stable.
This is necessary in order for type checkers to allow creating one code object from another, since the `lnotab`
positional argument to `__init__` is typed as bytes.
Use the `| Any` trick instead, since it seems that in a lot of
code the value can be predicted to be non-`None` (if a query
has been executed previously, I think).
The docs don't mention the possibility of this being `None`, so
it seems likely that a lot of code doesn't check for it:
https://docs.python.org/3/library/sqlite3.html#sqlite3.Cursor.description
```
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))])
```
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.
