Mailman 3 July 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

Opened and changed typing issues week 2023-W30
by Typing Bot 30 Jul '23

30 Jul '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 updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 --------------------------------------------------- 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

Opened and changed typing issues week 2023-W29
by Typing Bot 23 Jul '23

23 Jul '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 updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #801 Introduce a Not type opened by @antonagestam https://github.com/python/typing/issues/801 #1400 Consider adding a "TopLevel" keyword that stands in for the top level bound of a corresponding type variable opened by @NeilGirdhar https://github.com/python/typing/issues/1400 --------------------------------------------------- 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

Python 3.12: Should `TypeVar.__eq__` compare the typevar name and not the identity?
by Patrick Arminio 18 Jul '23

18 Jul '23

Hi there, I'm wondering if TypeVars should compare their name instead of their identity, for example here: ``` class Something[T]: abc: T class SomethingElse[T]: abc: T print(Something.__type_params__ == SomethingElse.__type_params__) # this is false ``` I have a library that uses generics quite a bit and I'm getting issues on Python 3.12 because the comparison doesn't work anymore (and also because we use TypeVars as key of a dictionary)

2 2

Opened and changed typing issues week 2023-W28
by Typing Bot 16 Jul '23

16 Jul '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 updated last week: #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #786 Feature Request: Type hint for Fixed Length Homogeneous Sequences opened by @craigh92 https://github.com/python/typing/issues/786 #801 Introduce a Not type opened by @antonagestam https://github.com/python/typing/issues/801 --------------------------------------------------- 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

Sprint at Europython about Intersection & Not Operator as well kwargs copy function
by Kound 14 Jul '23

14 Jul '23

Dear everybody, next week the Europython in Prague starts. At the end of the week there will be sprints and even being my first Europython and never having written a PEP I really want to use the opportunity to bring some typing topics forward. So I decided to host a sprint for these three topics: - Intersection Operator (https://github.com/python/typing/issues/213) - Not Operator (https://github.com/python/typing/issues/801) - copy_kwargs function (https://stackoverflow.com/questions/71968447/python-typing-copy-kwargs-from…) Maybe some of you are at the Europython anyway, feel free to contact me. Also help on this topics is much appreciated. So if you have anything to contribute but aren't in Prague during these days, drop you notes in the issues or send me a mail :-) More information can be found under https://ep2023.europython.eu/sprints#typing-peps Best Regards, Carli*

1 0

What is the effect of py.typed?
by Paul Moore 13 Jul '23

13 Jul '23

I've had a request to add a `py.typed` file to one of my projects. It's fine, adding the file is a very minor thing and I don't have any problem doing so. But as the maintainer, I'd like to understand *why* this is necessary. I've looked at PEP 561, and it says "Package maintainers who wish to support type checking of their code MUST add a marker file named py.typed to their package supporting typing". But I don't understand what it means to "wish to support type checking" - I have annotations in my code, I can run mypy on the code and it flags any issues, everything just works. What do I lose by *not* having a `py.typed` file? I've read (skimmed, to be fair) the PEP and the linked mypy documentation, and I can't find an answer to that question. Thanks, Paul

9 25

Opened and changed typing issues week 2023-W27
by Typing Bot 09 Jul '23

09 Jul '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 updated last week: #513 Typing for multi-dimensional arrays opened by @shoyer https://github.com/python/typing/issues/513 #786 Feature Request: Type hint for Fixed Length Homogeneous Sequences opened by @craigh92 https://github.com/python/typing/issues/786 --------------------------------------------------- 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

Let's deprecate `@no_type_check_decorator`
by Alex Waygood 03 Jul '23

03 Jul '23

Hi, I recently posted a proposal to deprecate `typing.no_type_check_decorator` in Python 3.13, with a view to removing it in Python 3.15: https://github.com/python/cpython/issues/106309. `typing.no_type_check` and `typing.no_type_check_decorator` have both been in the typing module since its introduction in Python 3.5. However, the two decorators have been on a different journey since then. Some (though not all) major type checkers have added support for `typing.no_type_check`, and, while it's far from being a flagship feature of the typing module, it's reasonably popular among users. `typing.no_type_check_decorator`, on the other hand, has not (to my knowledge) had support added by any major type checkers in the past eight years, and has very little usage. While there have been a few feature requests to type checkers asking them to add support for `typing.no_type_check_decorator`, none of them have received many upvotes. At this point, I don't think it's worth it for type checkers to add support for `typing.no_type_check_decorator`, and I think it's unlikely that they ever will, or should. As such, continuing to advertise its existence in the typing module is frankly misleading to users. I therefore propose that we deprecate it, and schedule its removal. (I do not propose that we deprecate `typing.no_type_check.) If anybody objects to these plans, please comment on the GitHub issue — it's important that we don't remove anything unless there's consensus behind doing so! Thanks, Alex

6 8