Mailman 3 October 2022 - Typing-sig

Opened and changed typing issues week 2022-W43
by Typing Bot 30 Oct '22

30 Oct '22

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #182 Define a JSON type opened by @brettcannon https://github.com/python/typing/issues/182 #1043 TypingError: type checker will emit error with a message specified in typing stubs opened by @Akuli https://github.com/python/typing/issues/1043 #1273 Type lookup table for generics opened by @jonathanslenders https://github.com/python/typing/issues/1273 --------------------------------------------------- All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

Partial type (similar to typescript)
by Patrick Arminio 27 Oct '22

27 Oct '22

Hi folks! I just wanted to get feelings on having something like Partial in TypeScript. The way it works is that it makes every key inside a TS type/interface optional. Here's an example of how it works: https://www.typescriptlang.org/play#code/JYOwLgpgTgZghgYwgAgCoHsAm7kG8BQyyY… For a library I work on we might have an use case that could use a way to make a partial class from another class, for example: ``` @dataclass class Todo: title: str description: str def update_todo(todo: Todo, fields_to_update: Partial[Todo]) -> Todo: ... todo1 = Todo(title="organize desk", description="clear clutter"); update_todo(todo1, Partial[Todo](description="Something")) ``` I purposely didn't do the example using typed dicts, mostly because I was curious to see if we can find a nice API that can work for classes too. And my example is a test 😊 What do you think? Do you see us having a Partial type that *also* works with classes?

8 9

PEP 688: Request for feedback on bytes/bytearray promotion
by Jelle Zijlstra 27 Oct '22

27 Oct '22

I recently revised PEP 688 (https://peps.python.org/pep-0688/), which proposes a mechanism to make the buffer protocol accessible to the type system. The most technically challenging part of the PEP is in the interaction with the C API, so I opened a primary discussion thread on the core dev Discourse at https://discuss.python.org/t/pep-688-take-2-making-the-buffer-protocol-acce… . However, the PEP also proposes a change that affects primarily static type checkers: removing the implicit promotion of memoryview and bytearray to bytes. For context, the CPython docs currently specify that a type annotation of "bytes" should also include bytearray and memoryview values, similar to how "float" implicitly includes int. Mypy and pyright implement this rule; pyre does not. I have a draft mypy PR removing the implicit promotion at https://github.com/python/mypy/pull/12661. The mypy-primer output shows that it is not uncommon for projects to rely on the implicit promotion. (Though it's worth noting that a maintainer of the most impacted project, psycopg, asked mypy to remove the implicit promotion because it caused mypy to miss bugs: https://github.com/python/mypy/issues/12643#issuecomment-1105914159.) Several people commented on Discourse that they feel it is more intuitive for newcomers if a bytes type annotation also includes bytearray. The more I think about it, the more I'm convinced that it's better in the long term to remove this implicit promotion. The most basic rule in Python typing is that if you put a type X in an annotation, only instances of that type are accepted. Exceptions to that rule are counterintuitive and lead to confusing edge cases. If you want either bytes or bytearray, you should write "bytes | bytearray"; if you want just bytes, you should write "bytes". But I'm willing to change the PEP if the consensus in the typing community is that it's better to keep the implicit bytes/bytearray promotion. What do you think? I'm less willing to keep accepting memoryview as compatible with bytes. bytearray really does have almost perfect interoperability with bytes (the main exception is that it's not hashable), but memoryview has little in common with bytes beyond being a buffer.

6 6

Type annotation coverage for most downloaded PyPI packages
by Graham Wheeler 26 Oct '22

26 Oct '22

I thought this might be of general interest. I leveraged pyright's ability to generate type coverage scores of the most downloaded PyPI packages (I used August top 1000). A few are missing, because they either failed to pip install on my MacBook or they are native code. I also looked for type stubs, looking first in typeshed, then for a '<package>-stubs' package, then 'types-<package>', and included the version number of that package, if found. Overall, here was the distribution of scores for packages with py.typed: [image: image.png] And without: [image: image.png] You can see the detailed results at typescore/latest-scores.md at main · gramster/typescore (github.com) <https://github.com/gramster/typescore/blob/main/latest-scores.md> Thanks Graham

1 0

Typing an object based on its methods
by TobiasHT 26 Oct '22

26 Oct '22

Is it possible to type an object that comprises of certain user defined methods? I am writing a function that should accept a single argument which should be an instance of any object that implements two methods, get and post. Is their a way of creating a type for it that can be scanned by static type checkers?

3 3

Opened and changed typing issues week 2022-W42
by Typing Bot 23 Oct '22

23 Oct '22

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #1252 ParamSpec: use P.args and P.kwargs in other scopes, such as return types opened by @chadrik https://github.com/python/typing/issues/1252 #1273 Type lookup table for generics opened by @jonathanslenders https://github.com/python/typing/issues/1273 --------------------------------------------------- All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

Generic `typing.ForwardRef` to support generic recursive types
by Xuehai Pan 21 Oct '22

21 Oct '22

Originally posted at [Python Discussion: Generic typing.ForwardRef to support generic recursive types](https://discuss.python.org/t/generic-typing-forwardref-to-support-ge…. TL;DR: Generic recursive type annotations require `typing.ForwardRef` to support typevar substitution, like `Union`: ```python class _GenericAlias(_Final, _root=True): @_tp_cache def __getitem__(self, params): if self.__origin__ in (Generic, Protocol): # Can't subscript Generic[...] or Protocol[...]. raise TypeError(f"Cannot subscript already-subscripted {self}") if not isinstance(params, tuple): params = (params,) msg = "Parameters to generic types must be types." params = tuple(_type_check(p, msg) for p in params) _check_generic(self, params) return _subs_tvars(self, self.__parameters__, params) ``` Maybe we can add `__paramters__` attributes to `ForwardRef` and let it can support `_subs_tvars` in `_GenericAlias.__getitem__` (e.g. a `Union[...]`). ------ ## Original Post Since v0.981 `mypy` supports recursive types and will be enabled by default since v0.990. E.g.: ```python JSON = Union[Dict[str, 'JSON'], List['JSON'], str, int, float, bool, None] ``` Recursive types need to use `ForwardRef`s at the right-hand side to reference the type alias before assignment. The ref `ForwardRef('JSON')` is not generic parameterized. I'm trying to annotate an arbitrarily nested container with a specific element type or parameterized by a typevar. For example: ```python T = TypeVar('T') PyTree = Union[ T, Tuple['PyTree[T]', ...], # Tuple, NamedTuple List['PyTree[T]'], Dict[Any, 'PyTree[T]'], # Dict, OrderedDict, DefaultDict ] ``` since the typevar `T` is inside a string `'PyTree[T]'`, which will be converted to a `ForwardRef`. However, it will be never evaluated because it is not assigned to a variable (`PyTree[T]` is not a valid identifier either). So I get: ```python >>> TreeOfInts = PyTree[int] >>> TreeOfInts typing.Union[int, typing.Tuple[ForwardRef('PyTree[T]'), ...], typing.List[ForwardRef('PyTree[T]')], typing.Dict[typing.Any, ForwardRef('PyTree[T]')]] ``` `Union` only substitutes the first `T` to `int` which not in `ForwardRef`s, while the remaining `ForwardRef`s are remained as `ForwardRef('PyTree[T]')`. As an alternative, I can specify the `int` type as: ```python >>> TreeOfInts = Union[int, Tuple['TreeOfInts', ...], List['TreeOfInts'], Dict[Any, 'TreeOfInts']] >>> TreeOfInts typing.Union[int, typing.Tuple[ForwardRef('TreeOfInts'), ...], typing.List[ForwardRef('TreeOfInts')], typing.Dict[typing.Any, ForwardRef('TreeOfInts')]] ``` But this approach is not considered because it is impossible to cover all element types for function annotations. E.g: ```python def tree_leaves( tree: PyTree[T], is_leaf: Optional[Callable[[T], bool]] = None, *, none_is_leaf: bool = False, ) -> List[T]: ... ``` Is it possible to make `ForwardRef` generic? Or is there any other way to define a generic recursive type (for function annotations)? References: * [Support recursive types python/mypy#731](https://github.com/python/mypy/issues/731) * [Recursive Generic Type Support python/mypy#13693](https://github.com/python/mypy/issues/13693) * [Type checking for pytrees google/jax#3340](https://github.com/google/jax/issues/3340) * [Better Type Annotation Support for PyTrees metaopt/optree#6](https://github.com/metaopt/optree/issues/6)

1 0

TypedDict with dict comprehension
by Paul Bryan 19 Oct '22

19 Oct '22

I see that both mypy and pyright both reject TypedDict being constructed with a dict comprehension, which from a static typing perspective is understandable. I do question if it's the correct behavior though. I have multiple dynamic typing cases where I construct a TypedDict using a dict comprehension a la: TypedDict("TD", {n: t for n, t in ...}). I propose static type checkers interpret this as equivalent to dict[Any, Any], and not flag it as an error (and not show red underlines in various IDEs), as there is nothing I can see in the documentation to prohibit it and works at runtime as expected.

4 7

Opened and changed typing issues week 2022-W41
by Typing Bot 16 Oct '22

16 Oct '22

The following is an overview of all issues and pull requests in the typing repository on GitHub with the label 'topic: feature' that were opened or updated last week, excluding closed issues. --------------------------------------------------- The following issues and pull requests were opened last week: #1273 Type lookup table for generics opened by @jonathanslenders https://github.com/python/typing/issues/1273 --------------------------------------------------- The following issues and pull requests were updated last week: #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 --------------------------------------------------- All issues and pull requests with the label 'topic: feature' can be viewed under the following URL: https://github.com/python/typing/issues?q=label%3A%22topic%3A+feature%22

1 0

Compact syntax for Callable: using dicts
by Nikita Sobolev 15 Oct '22

15 Oct '22

Hello everyone, Since PEP with new callable syntax was rejected, I would like to propose another idea. It is quite simple, but yet powerful enough for our main use-cases. We can use `Callable[{'arg_name': arg_type}, ret_type]` syntax. It is an allowed syntax and python3.10+ can work with it out of the box: ``` Python 3.10.0 (default, Nov 1 2021, 10:24:06) [Clang 11.0.0 (clang-1100.0.33.16)] on darwin >>> from typing import Callable >>> Callable[{}, int] typing.Callable[[{}], int] ``` It supports multi-line readable format: ``` >>> func: Callable[{ ... 'a': int, ... 'b': str, ... }, int] ``` How can it solve our main problems? 1. It clearly supports argument names: `{'arg_name': int}` 2. It can support positional only arguments via: `{'__arg_name': int}` or `{'/arg_name': int}` 3. It can support args and kwargs: `{'*': int, '**': str}` 4. It can support kw-only arguments: `{'*kw_arg': type}` 5. It can support any arguments with default values: `{'required_arg': int, 'has_default': typing.NotRequired[str]}`, because the exact default value is not a part of the function signature This change does not require any parser changes, only semantic ones in `typing.py` and type-checkers. Old `Callable` semantics with `[]` will stay the same. Probably older python versions would need to use `typing_extensions.Callable` to have this feature. Old pythons raise an error for `{}` use in `Callable`: ``` Python 3.7.11 (default, Jul 16 2021, 15:35:56) >>> from typing import Callable >>> Callable[{}, int] Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/Users/sobolev/.pyenv/versions/3.7.11/lib/python3.7/typing.py", line 760, in __getitem__ raise TypeError(f"Callable[args, result]: args must be a list." TypeError: Callable[args, result]: args must be a list. Got {} ``` Later we can reuse quite similar syntax for in-place typed-dict definitions: ``` def expects_user(user: {'email': str, 'age': int}): print(user['email'], user['age']) ``` What do other think about this idea? :)

2 1