Mailman 3 May 2023 - Typing-sig

Re: Typing Meetup
by S Pradeep Kumar 19 Sep '23

19 Sep '23

Updating the Typing Meetup date to Wednesday as there were some conflicts. Let me know if there are any major time conflicts. Date: *Wednesday, November 03, 2021.*Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC) Duration: 1 hour Potential discussion topics: + Typing **kwargs using a TypedDict (Franek Magiera?, Pradeep) [1] + Remaining questions about Callable syntax (Steven) + Non-required Protocol fields (Sebastian Rittau?) [2] + Type support for sealed classes (Adrian Freund?) [3] + Safe, typed JSON validation + Type system documentation (Shannon?) If you're working on these or any other topics and would like to start a discussion at the meetup, reach out to me. If you have interesting topics you'd like to see discussed, share them too. Once we have topics, we can always start a discussion even if there's no proposer yet. We will probably have time for 3-4 topics in this session. On Fri, Oct 15, 2021 at 12:55 PM S Pradeep Kumar <gohanpra(a)gmail.com> wrote: >>> >>>> Hello all, >>>> >>>> We plan to hold a virtual Typing Meetup to discuss key typing-related >>>> issues in real-time. The idea is that we can make progress on important or >>>> controversial discussions, get early feedback on in-progress PEPs, and >>>> gauge interest in new proposals. >>>> >>>> A virtual meetup will be more accessible to people in other timezones >>>> than Bay Area in-person meetups. It should also help consolidate >>>> discussions that are often spread out across mailing lists or Github repos. >>>> The tentative plan is to have a monthly meetup, but we can change that as >>>> needed. >>>> >>>> Date: Monday, November 01, 2021. >>>> Time: 10 am San Francisco time (UTC-7) / 5 pm London time (UTC) >>>> Duration: 1 hour >>>> >>>> Time and date are flexible. I'll share the zoom link and agenda the >>>> week before. I'll also record the meetup and share afterwards. >>>> >>>> If you're interested in presenting a new proposal or your work on some >>>> existing proposal, please respond here. We can shoot for 15 minutes per >>>> presentation. I know there are quite a few interesting threads on >>>> typing-sig that haven't seen much activity in a while :) >>>> -- >>>> S Pradeep Kumar >>>> _______________________________________________ >>>> Typing-sig mailing list -- typing-sig(a)python.org >>>> To unsubscribe send an email to typing-sig-leave(a)python.org >>>> https://mail.python.org/mailman3/lists/typing-sig.python.org/ >>>> Member address: guido(a)python.org >>> >>> Links: [1] Typing **kwargs using TypedDict: https://mail.python.org/archives/list/typing-sig@python.org/thread/IUCXT2IQ… [2] Non-required Protocol fields: https://mail.python.org/archives/list/typing-sig@python.org/thread/P6FCGRJU… [3] Sealed classes: https://mail.python.org/archives/list/typing-sig@python.org/thread/QSCT2N4R… -- S Pradeep Kumar

10 60

Type narrowing for TypeGuard in the negative case
by Eric Traut 04 Aug '23

04 Aug '23

Since the introduction of PEP 647 (User-defined Type Guards), we've received a steady stream of input from users saying that they don't like the limitation that type narrowing is applied only in the positive case and is not applied in the negative case. In general, type narrowing is not safe to perform if a user-defined type guard returns False, so I've stood by the original decision not to provide type narrowing in the negative case, but there are cases where such narrowing is safe and desirable. Here's a recent thread where this was discussed in some detail: https://github.com/python/typing/issues/996#issuecomment-1002716830 In this discussion, Ilya Kamen proposed a solution. The proposal is to extend the existing `TypeGuard` to support an optional second type argument. If present, the second argument indicates the narrowed type in the negative type narrowing situation. Here's a simple (admittedly contrived) example: ```python def is_str(val: str | int) -> TypeGuard[str, int]: return isinstance(val, str) def func(val: str | int): if is_str(val): reveal_type(val) # str else: reveal_type(val) # int ``` I've implemented this proposal in the latest published version of pyright (1.1.202) so folks can experiment with it and see if they like it. If there's general consensus that it's the right approach, I can file an amendment for the existing PEP 647 to include this functionality. It was trivial to add to pyright, so I'm optimistic that it would likewise be easy to add to the other type checkers. Another common request for PEP 647 is the desire for an "assert" form of TypeGuard — a way to indicate that a function performs runtime validation of a type, raising an exception if the type is incorrect. It occurred to me that this two-argument form of `TypeGuard` could also be used to handle this use case. The second argument would be specified as a `NoReturn`. I've provisionally implemented this in pyright as well (although it's not in the currently-published version — you'll need to wait until 1.1.203 is published). Here's what this would look like: ```python def validate_sequence(val: Sequence[_T | None]) -> TypeGuard[Sequence[_T], NoReturn]: """Verifies that the sequence contains no None values""" if len([x for x in val if x is not None]) > 0: raise Exception() return True def func(val: Sequence[int | None]): validate_sequence(val) reveal_type(val) # Sequence[int] ``` I'm interested in input on these proposals. -Eric -- Eric Traut Contributor to Pyright & Pylance Microsoft

7 8

Any way to express that a dict is expected to have a key(s) but don't care about other keys?
by Brett Cannon 20 Jun '23

20 Jun '23

Looking at TypedDict it seems that it does not like the idea of superfluous keys existing in a dict. In my case I have a REST call returning JSON for an error and all I'm guaranteed is to get an "error" key. But there may be extra keys that provide more details about the specific error. Unfortunately I don't know the exhaustive list of keys so I can't use a TypedDict with `totality == False` to try to be complete. I can't think of any way to somehow say "require/expect this one key, but other keys are OK". Am I missing anything that would let me do this?

17 35

Inline syntax for TypedDict
by Никита Соболев 14 Jun '23

14 Jun '23

Hi everyone! ## Problem Dicts are fundamental to Python programming. And today I found myself writing this piece of code (again): ```python def process_user(user_dict: User) -> ModifiedUser: ... class User(TypedDict): ... class ModifiedUser(User): ... ``` While in reality it was as simple as: `{'user_id': int}` -> `{'user_id': int, 'external_id': int}` What really bothers me is that I have to either: 1. Create a new whole class for it 2. Create a new type variable in a form of `User = TypedDict('User', {...})` I think that it hurts the readability quite a lot, because the definition of this type might not be near with a function that uses it. Another problem is that due to the nature of `TypedDict`s there are quite a lot of them in a regular web application, because of json. The biggest problem (for me personally) is that you cannot simply nest TypedDict. So, if you have a nested dict that you want to use, like `{'user': {'email': str}}`? You have to define *two* classes. And the final touch: it looks like many TypedDict are just used in one place. They are just like throw-away definitions. And don't forget that classes cannot have all keys in their body: `return`, `@1`, etc are all not allowed. ## Proposal To solve all the problems above, I propose adding "inline" syntax for typed dicts: ```python def get_user_data(arg: {'user': {'email': str}}) ->{'email': str}: return user['user'] ``` It has great potential: 0. Grammar already allows that with no changes from our side 1. `Required` and `NotRequired` can be used to enforce the presence of keys and values 2. Dicts can be nested with ease, just like in my example. Even multiline nesting is supported: ```python >>> def multiline() -> { ... 'user': { ... 'email': str, ... }, ... }: ... ... ... ``` 3. The intent is pretty clear: any user familiar with dicts would be able to read and understand this code 4. Other languages already have this feature, TS example: https://www.typescriptlang.org/play?#code/GYVwdgxgLglg9mABAcwKZQPogM6oE4YAm… 5. Existing tooling continues to work, see this example: ```python >>> import typing >>> def get_user_data(arg: {'user': {'email': str}}) ->{'email': str}: ... ... >>> get_user_data.__annotations__ {'arg': {'user': {'email': <class 'str'>}}, 'return': {'email': <class 'str'>}} >>> typing.get_type_hints(get_user_data) {'arg': {'user': {'email': <class 'str'>}}, 'return': {'email': <class 'str'>}} ``` And: ```python >>> import typing >>> class Some: ... a: {'x': int} = {'x': 1} ... def method(self, arg: {'x': int}) -> {'x': int, 'y': int}: ... return {'x': 1, 'y': 2} ... >>> Some.__annotations__ {'a': {'x': <class 'int'>}} >>> Some.method.__annotations__ {'arg': {'x': <class 'int'>}, 'return': {'x': <class 'int'>, 'y': <class 'int'>}} >>> typing.get_type_hints(Some) {'a': {'x': <class 'int'>}} >>> typing.get_type_hints(Some.method) {'arg': {'x': <class 'int'>}, 'return': {'x': <class 'int'>, 'y': <class 'int'>}} ``` 6. It is just a regular dict! No new things to create :) ## Extra We can also discuss the variable syntax change from: ```python X = TypedDict('X', {'a': int}) ``` To: ```python X: TypeAlias = {'a': int} ``` Because again, it is simpler: no need to duplicate the name and values can be nested. ## Problems The most important problem I see is that it is just a syntax to solve a problem with an existing solution. But, I think it is a good addition overall. ## Typecheckers From what I know, it would not be too hard to support this in mypy. We would need to add new logic to generate names from context (instead of an explicit name). Nesting needs to be tested, we might have some troubles here. I cannot speak for other typecheckers. ## Feedback This is a very rough idea for now. But, what do you think? Is that a problem you face in your projects? I would be glad to hear the feedback from the Python's typing community :) Best, Nikita Sobolev

14 28

Runtime Access to Type Parameters
by Saul Shanabrook 07 Jun '23

07 Jun '23

I would like to propose being able to access, at runtime, the type parameters in classmethods and in constructors. I wrote up a draft PEP on this to capture the thinking here: https://github.com/saulshanabrook/peps/blob/master/pep-9999.md It seems easier to add them to classmethods, so even that addition alone would be very welcome! It could be added to Guido's existing draft PR for pep 585, by making a small change in the getattr function (https://github.com/python/cpython/pull/18239/files#diff-a34ae826f869897e56e…), to first do a `__getattribute__` and check if the result is a descriptor (has a `__get__` attribute), and if so passing the generic class itself in as the class, instead of the origin class. I wrote up a little example of that in the PEP. To make it available in the constructor, I proposed adding a global function `get_parameters` to `typing` which returns the parameters in the constructor. I also provide a little mock implementation of that. Note that work is only for custom classes which inherit from `typing.Generic` not for any built in collections.

5 6

Opened and changed typing issues week 2023-W21
by Typing Bot 29 May '23

29 May '23

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: #1405 Generic ParamSpec in subclass definitions opened by @alanhdu https://github.com/python/typing/issues/1405 --------------------------------------------------- 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

Release: typing-extensions 4.6.0
by Jelle Zijlstra 23 May '23

23 May '23

I just released typing-extensions 4.6.0: https://pypi.org/project/typing-extensions/4.6.0/ This release comes with documentation at https://typing-extensions.readthedocs.io/en/latest/ (previously typing-extensions was documented only through its README). In addition, there is a large number of additions and improvements. Copying from the changelog: - `typing_extensions` is now documented at https://typing-extensions.readthedocs.io/en/latest/. Patch by Jelle Zijlstra. - Add `typing_extensions.Buffer`, a marker class for buffer types, as proposed by PEP 688. Equivalent to `collections.abc.Buffer` in Python 3.12. Patch by Jelle Zijlstra. - Backport two CPython PRs fixing various issues with `typing.Literal`: https://github.com/python/cpython/pull/23294 and https://github.com/python/cpython/pull/23383. Both CPython PRs were originally by Yurii Karabas, and both were backported to Python >=3.9.1, but no earlier. Patch by Alex Waygood. A side effect of one of the changes is that equality comparisons of `Literal` objects will now raise a `TypeError` if one of the `Literal` objects being compared has a mutable parameter. (Using mutable parameters with `Literal` is not supported by PEP 586 or by any major static type checkers.) - `Literal` is now reimplemented on all Python versions <= 3.10.0. The `typing_extensions` version does not suffer from the bug that was fixed in https://github.com/python/cpython/pull/29334. (The CPython bugfix was backported to CPython 3.10.1 and 3.9.8, but no earlier.) - Backport [CPython PR 26067](https://github.com/python/cpython/pull/26067) (originally by Yurii Karabas), ensuring that `isinstance()` calls on protocols raise `TypeError` when the protocol is not decorated with `@runtime_checkable`. Patch by Alex Waygood. - Backport several significant performance improvements to runtime-checkable protocols that have been made in Python 3.12 (see https://github.com/python/cpython/issues/74690 for details). Patch by Alex Waygood. A side effect of one of the performance improvements is that the members of a runtime-checkable protocol are now considered “frozen” at runtime as soon as the class has been created. Monkey-patching attributes onto a runtime-checkable protocol will still work, but will have no impact on `isinstance()` checks comparing objects to the protocol. See ["What's New in Python 3.12"]( https://docs.python.org/3.12/whatsnew/3.12.html#typing) for more details. - `isinstance()` checks against runtime-checkable protocols now use `inspect.getattr_static()` rather than `hasattr()` to lookup whether attributes exist (backporting https://github.com/python/cpython/pull/103034). This means that descriptors and `__getattr__` methods are no longer unexpectedly evaluated during `isinstance()` checks against runtime-checkable protocols. However, it may also mean that some objects which used to be considered instances of a runtime-checkable protocol on older versions of `typing_extensions` may no longer be considered instances of that protocol using the new release, and vice versa. Most users are unlikely to be affected by this change. Patch by Alex Waygood. - Backport the ability to define `__init__` methods on Protocol classes, a change made in Python 3.11 (originally implemented in https://github.com/python/cpython/pull/31628 by Adrian Garcia Badaracco). Patch by Alex Waygood. - Speedup `isinstance(3, typing_extensions.SupportsIndex)` by >10x on Python <3.12. Patch by Alex Waygood. - Add `typing_extensions` versions of `SupportsInt`, `SupportsFloat`, `SupportsComplex`, `SupportsBytes`, `SupportsAbs` and `SupportsRound`. These have the same semantics as the versions from the `typing` module, but `isinstance()` checks against the `typing_extensions` versions are >10x faster at runtime on Python <3.12. Patch by Alex Waygood. - Add `__orig_bases__` to non-generic TypedDicts, call-based TypedDicts, and call-based NamedTuples. Other TypedDicts and NamedTuples already had the attribute. Patch by Adrian Garcia Badaracco. - Add `typing_extensions.get_original_bases`, a backport of [`types.get_original_bases`]( https://docs.python.org/3.12/library/types.html#types.get_original_bases), introduced in Python 3.12 (CPython PR https://github.com/python/cpython/pull/101827, originally by James Hilton-Balfe). Patch by Alex Waygood. This function should always produce correct results when called on classes constructed using features from `typing_extensions`. However, it may produce incorrect results when called on some `NamedTuple` or `TypedDict` classes that use `typing.{NamedTuple,TypedDict}` on Python <=3.11. - Constructing a call-based `TypedDict` using keyword arguments for the fields now causes a `DeprecationWarning` to be emitted. This matches the behaviour of `typing.TypedDict` on 3.11 and 3.12. - Backport the implementation of `NewType` from 3.10 (where it is implemented as a class rather than a function). This allows user-defined `NewType`s to be pickled. Patch by Alex Waygood. - Fix tests and import on Python 3.12, where `typing.TypeVar` can no longer be subclassed. Patch by Jelle Zijlstra. - Add `typing_extensions.TypeAliasType`, a backport of `typing.TypeAliasType` from PEP 695. Patch by Jelle Zijlstra. - Backport changes to the repr of `typing.Unpack` that were made in order to implement [PEP 692](https://peps.python.org/pep-0692/) (backport of https://github.com/python/cpython/pull/104048). Patch by Alex Waygood. Please report any issues at https://github.com/python/typing_extensions/issues.

1 0

PEP 695: "Type Parameter Syntax" accepted
by Alfonso L. Castaño 22 May '23

22 May '23

I haven't seen it published in this mailing list so sharing for visibility: https://discuss.python.org/t/pep-695-type-parameter-syntax/21646/92 https://peps.python.org/pep-0695/ Thank you very much for your effort Eric, and congratulations. I am personally very excited about this PEP!

1 0

Opened and changed typing issues week 2023-W20
by Typing Bot 22 May '23

22 May '23

No issues or pull requests with the label 'topic: feature' were opened or updated last week in the typing repository on GitHub. 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

Why isn't a specialized generic class a subclass of its non-specialized version?
by Kevin Millikin 16 May '23

16 May '23

I'm working on implementing narrowing for `issubclass` checks and I find the runtime behavior of this kind of surprising: >>> issubclass(list[int], list) False Why isn't list[int] a subclass of list? It seems inconsistent with the runtime behavior of this: >>> x: list[int] = [1, 2, 3] >>> isinstance(x, list) True -- [image: logo] Kevin Millikin Software Engineer kmillikin(a)deepmind.com If you received this email in error, please do not forward it to anyone else (it may contain confidential or privileged information), erase all copies and attachments, and let me know that it has gone to the wrong person.

3 4