Mailman 3 - Typing-sig

Draft PEP for Improved Type Parameter Syntax
by Eric Traut 24 Jun '22

24 Jun '22

In last month's typing meetup, Sebastian presented some options for improving the syntax for type parameters. I subsequently posted some slides that explored a bunch of options. For reference, here's a link to those slides: https://docs.google.com/presentation/d/1aVHTaj8zGYAvM27uft1ktdthwEKO4KH4qaR…. In the interest of continuing to make progress on this topic, I've drafted a PEP that places some stakes in the ground. Here's a link to the PEP: https://github.com/erictraut/peps/blob/typeparams/pep-9999.rst. I'm interested in feedback. Since there appears to be broad interest in addressing this problem, perhaps we can use the next typing meetup to continue this discussion. -- Eric Traut Contributor to Pyright & Pylance Microsoft

5 10

Re: Typing Meetup
by S Pradeep Kumar 23 Jun '22

23 Jun '22

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

8 37

Opened and changed typing issues week 2022-W24
by Typing Bot 19 Jun '22

19 Jun '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: #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

Re: PEP 692: Using TypedDict for more precise **kwargs typing
by Станислав Терляков 19 Jun '22

19 Jun '22

Thank you for your efforts! I'm glad to see this promising attempt to allow using TypedDict for **kwargs precise typing. It is amazing, I have seen many use cases for that, often to make stub code more DRY and close to the original implementation (requests, where get, post, etc. share signature [1], django-stubs with model fields - more than 10 arguments with non-trivial signatures [2]). I have a question regarding point 3 in the "assignment" chapter. Why should this be considered safe? mypy rejects the following code: def foo(*, title: str, year: int = ...) -> int: # same as **kwargs: **Movie ... def bar(title: str, year: int = ...) -> int: ... bar = foo # E: Incompatible types in assignment (expression has type "Callable[[NamedArg(str, 'title'), DefaultNamedArg(int, 'year')], int]", variable has type "Callable[[str, int], int]") The reason is that foo('a', 0) was allowed before assignment and fails after it (positional-or-keyword parameters should not be substituted with keyword-only). So why should essentially the same code be allowed with TypedDict? def foo(**kwargs: **Movie): ...def bar(title: str, year: int = ...): ... bar = foo # OK! # <-- Why is it allowed? I think that keyword-only notation must be required in this case for consistency and will be more semantically correct. I apologise in advance for any mistakes here - I haven't participated in typing-sig before. [1] https://github.com/python/typeshed/blob/master/stubs/requests/requests/sess… [2] https://github.com/typeddjango/django-stubs/blob/master/django-stubs/db/mod…

2 1

PEP 692: Using TypedDict for more precise **kwargs typing
by Franek Magiera 15 Jun '22

15 Jun '22

Adding support for more precise **kwargs (consisting of different types) typing using TypedDict has been a very desired feature in python community [1]. The feature proposal has been discussed both on the mailing list and at a typing meetup and received positive feedback. I've submitted PEP 692 that aims to add support for more precise **kwargs typing. The PR is available at https://github.com/python/peps/pull/2620 And the preview at https://pep-previews--2620.org.readthedocs.build/pep-0692/ - **kwargs can consist of different types - A new syntax `def foo(**kwargs: **Movie): ...` that enables the feature is introduced Please let me know what you think about it. Franek [1] https://github.com/python/mypy/issues/4441

4 6

How to annotate modifications for function arguments with `ParamSpec` and `TypeVar`
by Sebastián Ramírez 15 Jun '22

15 Jun '22

Not sure this is the right place to ask, but here we go... 😬 I want to be able to annotate something that takes a function and creates a new one that alters the argument types it accepts. A quick example, using Ray <https://github.com/ray-project/ray>: import rayray.init() @ray.remotedef do_things(x: int, y: float): return x * y @ray.remotedef do_more_things(name: str, value: float): return f"{name}: {value}" pure_value = do_things(x=3, y=2.2) # pure_value is type: float ref_value = do_things.remote(x=3, y=2.2) # ref_value is type: ObjectRef[float] pure_second_value = do_more_things(name="Foo", value=pure_value) # this is fineref_second_value = do_more_things.remote(name="Foo", value=ref_value) # this should be fine So, do_things() and do_more_things() should keep their signature. But their remote counterparts should have a signature that allows the original types or a wrapper ObjectRef[OriginalType] for each argument: do_things.remote(x: int | ObjectRef[int], y: float | ObjectRef[float]) -> ObjectRef[float]: ...do_more_things.remote(name: str | ObjectRef[str], value: float | ObjectRef[float]) -> ObjectRef[str]: ... Now, I know type annotating this in this particular API design is probably difficult, and possibly not easily supported yet. I was thinking of an alternative API that could take advantage of ParamSpec, TypeVars with overloads and/or TypeVarTuple. But I still can't find a way to get all the desired features together. Longer discussion and ideas I tried: https://github.com/python/typing/discussions/1163 --- Assuming this is currently not possible, what would be needed to make it possible? Would some way of achieving this be acceptable? And if so, what would be the best approach to make it possible? I'm not sure what's the process, but maybe there could be a way to sponsor someone with the right expertise here to tackle it, I imagine it would require a PEP, work on mypy, not sure what else, but maybe I'm being naive in some way and it would require a different approach. Thanks for your help and ideas/feedback! Sebastián

2 2

Opened and changed typing issues week 2022-W23
by Typing Bot 12 Jun '22

12 Jun '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: #688 advanced SimpleNamespace typing opened by @itajaja https://github.com/python/typing/issues/688 --------------------------------------------------- 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

Allowing types being created from function calls
by Patrick Arminio 11 Jun '22

11 Jun '22

Hello there, I was wondering if you see in future the python type system being able to allow creating types from function call. I'm asking this because I've designed an API for a library that doesn't really work well with the type system at the moment[1]. It looks something like this: ```python def union( name: str, types: Tuple[Types, ...], * ) -> Union[Types]: # implementation is not important return None # type: ignore ``` and it can be used like so: ```python UserOrError = union("UserOrError", (User, Error)) x: UserOrError = User(name="Patrick") ``` We do this to add some information about the type (for example a name), but running a type checker on the code above gives you this error: > Illegal type annotation: variable not allowed unless it is a type alias My question was, should I deprecate this way of creating a custom type in favour of using, maybe annotated? So the users code would look like this? ```python UserOrError = Annotated[User | Error, union(name="UserOrError")] x: UserOrError = User(name="Patrick") ``` or maybe there's some plan to support creating types from function calls (or expressions in general, when they can be statically analysed)? This looks a bit more complicated, but I don't mind it too much. [1] we made it work for Mypy via a plugin.

3 3

Deprecate and remove type comments?
by Ethan Smith 08 Jun '22

08 Jun '22

Hi all, Recently I was thinking about the place of type comments in Python typing. As far as I am aware, mypy is the only typechecker that remains that still supports Python 2. I expect we will remove support for Python 2 before the end of the year (but we haven't decided anything on that yet). So what does this mean for type comments? I think it would be best if we no longer needed to support them. However, there are a couple of issues: 1. They are specified in PEP 484 so we would need a new PEP most likely to deprecate/remove them 2. There isn't an obvious replacement for for/with type comments, we'd need to figure out a reasonable replacement. Anyway, I thought I'd start this thread to kick off some discussion, I'd love to hear what others think and if people have ideas for syntax for with/for statements. Ethan He/Him

11 23

Almost accepting PEP 681 – Data Class Transforms
by Petr Viktorin 06 Jun '22

06 Jun '22

Hello, As an initial implementation that will be improved in the future, the specification in PEP 681 is fine. Feel free to add the decorator to Python 3.11 at your convenience. However, the PEP includes several worrying recommendations like: - we recommend that the maintainers of attrs move away from the legacy semantics and adopt auto_attribs behaviors by default. - We chose not to support this feature and recommend that attrs users avoid converters. - Attrs users should use the dataclass-standard eq and order parameter names instead. These are probably meant as recommendations from typing-sig, but an accepted PEP represents consensus of the entire Python community. A typing PEP is not an appropriate place to make recommendations like this, especially without reaching out to the maintainer of attrs. As far as I know,the attrs and pydantic libraries are using the reference implementation, but their authors weren't consulted on the PEP itself. Could you either change the wording (e.g. say that the unsupported features need bespoke type-checker functionality for proper type checking), or work with attrs to make the same recommendations in its documentation? Happy typing, — Petr, on behalf of the Steering Council

9 11

2022

2021

2020

2019

2018

Typing-sig