Mailman 3 January 2023 - Typing-sig

Support Algebraic Data Types with @sealed
by John Hagen 20 Mar '23

20 Mar '23

The original (superseded) PEP 622 proposed adding a @sealed decorator so that users could define algebraic data types (ADTs) that static type checkers could verify are `match`ed exhaustively: - https://peps.python.org/pep-0622/#sealed-classes-as-algebraic-data-types There is a somewhat fairly-upvoted question about ADTs in Python, indicating interest in this area: - https://stackoverflow.com/questions/16258553 @sealed would be very valuable towards making ADT usage within Python more type-safe. Is there any historical discussion about why @sealed was dropped from the final pattern matching PEP? What would be the next steps needed to push this forward? Would writing a new PEP be the next step?

15 32

Extending published stubs
by Irv Lustig 20 Mar '23

20 Mar '23

I'm the leader of the pandas-stubs project. In pandas, users can extend the library by creating their own accessor via `(a)pd.api.extensions.register_dataframe_accessor` (see https://pandas.pydata.org/docs/reference/api/pandas.api.extensions.register…). So for a `DataFrame`, if you do `(a)pd.api.extensions.register_dataframe_accessor("xyz")`, you now have `DataFrame.xyz` returning the class you annotated. Now suppose you want to create a stub for your new accessor, that would extend the existing pandas-stubs. AFAIK, there isn't a way to do something like this in a stub: ``` from pandas import DataFrame @typing.extend class DataFrame: def xyz(self) -> MyXyzClass: ... ``` The idea here is that there is a class (in this case, `DataFrame`) that already has stubs, and you want to add a method to it. Has this idea been discussed anywhere?

5 10

PyCon 2023 Typing Summit: Interest form
by S Pradeep Kumar 16 Mar '23

16 Mar '23

Hello all, PyCon 2023 is just a few months out. Jelle and I are looking forward to organizing the Typing Summit this year. We plan to be in-person in Salt Lake City, as we did last year. We have confirmed the Typing Summit with PyCon and will announce the exact date soon (tentatively a day before the main conference talks). We will try to record the event for those who cannot make it. For those who haven't attended before, the Typing Summit is a 3-4 hour event with a series of presentations and group discussions related to type checking. You can find the 2022 summit here: https://youtu.be/BNTkWQfqP_c If you are interested in attending, please fill out this form: https://forms.gle/yv1WnDoAVscg21vW8. This way, we can get a sense of the expected number of attendees and the topics you want to hear about. In a few weeks, we will send out another mail to typing-sig calling for presenters. Let us know if you have any questions. Best, Jelle Zijlstra Pradeep Kumar Srinivasan

1 2

Compatibility rules for method overrides
by Steven Troxler 21 Feb '23

21 Feb '23

In PEP 698 (regarding @typing.override), we had a section clarifying that this PEP does *not* add any additional rules about ensuring that subclass methods have type signatures that are compatible with those of superclasses [1]. The way we phrased it was to say that this was already required. After we requested review from the SC, Brett Cannon pointed out, correctly, that in fact no existing PEP says this should be true [2]. All of the existing type checkers do require at least some compatibility, because to not do so would be unsound - for example the following code will fail and we would want type checkers to catch it: ```python class A: def f(self) -> int: return 5 class B: # incompatible override, return class is not a subtype of the return class `int` in parent method def f(self) -> str: return "5" a: A = B() x = 5 + a.f() # Runtime type error! ``` The rule of thumb for compatibility is that all legal function calls for the parent method should be legal, and the output of the subclass method should have a value that is of the type of the parent method return annotation. This implies several specific rules, depending exactly how many edge cases a particular type checker wants to catch - the ones I can think of off the top of my head being: (a) the return annotation on a subclass method should be a subtype of that on the parent class (b) for any parameter in the parent signature, the subclass parameter should be a supertype of what is declared in the parent method (c) named parameter names should not change, that would invalidate some calls (d) new positional or named parameters should have default values, otherwise you could get missing argument errors (e) if the parent type has a *args, then new positional-only / named params must be a supertype of the *args type (f) if the parent type has a *kwargs, then new named / keyword-only params must be a supertype of the *kwargs type I'm not sure whether all type checkers enforce all these rules - some of them (especially the *args and **kwargs limitations) might be obtrusive enough to merit trading off soundness. But my main question is simply: should we try to declare this behavior somewhere in the PEPs repo? We could potentially formalize the rule in a new PEP, or perhaps just add a note to PEP 484 (I believe this is Guido's preference, I'm not sure how clarifying existing PEPs works but that does seem better than a new PEP to me). -------------- [1] PEP 698 compatibility section, prior to Brett's objection: https://github.com/python/peps/blob/c34268dd5b7a2344437ea2785bbb2e1340226b0… [2] Discussion in steering-council issue regarding compatibility: https://github.com/python/steering-council/issues/160

3 2

PEP 698 typing.override
by Steven Troxler 02 Feb '23

02 Feb '23

A few weeks back we merged PEP 698 for `typing.override` as a draft PEP, with no significant changes since the typing-sig discussion in [1] One of the things we decided for the initial proposal was to avoid any runtime behavior; we considered setting `__override__` but decided not to because (a) it is hard to get the ordering of decorators right for runtime behavior, it depends on which decorators are descriptor- versus wrapper-function-based (b) some objects have fixed slots and therefore cannot have `__override__` set at all, there's no way to produce runtime behavior in these cases I think we should reconsider for two reasons: (a) The author of the overrides library got back to us and specifically requested this [2], because he believes there's potential for libraries to make runtime use of @override, for example automatically applying docstrings from parent classes to child classes which could be useful for notebook users (b) We do indeed set a `__final__` attribute in the @final decorator [3], and after some more thought I think consistency is important My current opinion is that we should make a best-effort attempt to set the attribute (as we do in `(a)typing.final`) and document edge cases that can impact runtime behavior, while ignoring those edge cases in static checkers. Are there any objections before I start working on these changes? ------------------- [1] Previous thread about typing.override proposal: https://mail.python.org/archives/list/typing-sig@python.org/message/7JDW2PK… [2] Discussion in peps repo regarding `__override__` https://github.com/python/peps/pull/2830 [3] @typing.final logic today: https://github.com/python/cpython/blob/main/Lib/typing.py#L2630-L2636

4 7

Opened and changed typing issues week 2023-W04
by Typing Bot 29 Jan '23

29 Jan '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: #1337 `typing.TYPE_CHECKER` object to change types depending on which type checker is being run opened by @Lunarmagpie https://github.com/python/typing/issues/1337 #1339 Support `sys.implementation.name` as feature switch for stubs opened by @cdce8p https://github.com/python/typing/issues/1339 --------------------------------------------------- The following issues and pull requests were updated last week: #786 Feature Request: Type hint for Fixed Length Homogeneous Sequences opened by @craigh92 https://github.com/python/typing/issues/786 #1160 Allow `float("inf")` and `float("-inf")` in literals opened by @antonagestam https://github.com/python/typing/issues/1160 #1304 range typing opened by @Godwhitelight https://github.com/python/typing/issues/1304 --------------------------------------------------- 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-W03
by Typing Bot 22 Jan '23

22 Jan '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: #566 AnyOf - Union for return types opened by @srittau https://github.com/python/typing/issues/566 --------------------------------------------------- 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

PEP 702: Marking deprecations using the type system
by Jelle Zijlstra 22 Jan '23

22 Jan '23

I just posted PEP 702, Marking deprecations using the type system: https://peps.python.org/pep-0702/. The PEP proposes adding an @typing.deprecated() decorator to mark classes, methods, and functions as deprecated. Type checkers will leverage this decorator to inform users about their usage of deprecated features. I welcome feedback on any aspect of the proposal. However, two main points came up in initial discussions: - The proposal specifies that the decorator does not raise any runtime DeprecationWarning. Should we change this, perhaps with an opt-in flag? - The proposal allows users to mark classes, functions, and overloads as deprecated, but there are other things that may want deprecation. Should we add support for deprecating modules, or variables, or parameters? Happy New Year!

5 5

Opened and changed typing issues week 2023-W02
by Typing Bot 15 Jan '23

15 Jan '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 #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

Extending LiteralString or Literal with structural validation
by Mathew Elman 09 Jan '23

09 Jan '23

I actually posted this in python-ideas and I was quickly suggested to come here instead: """ It would be useful to take advantage of the `LiteralString` or `Literal` type hints to add structural validation to literals. For *example*, if these could be subclassed to add a validation method: class MyLiteral(LiteralString): def __validate__(self): ... or extended to allow something like regex in there generic type parameter: Literal[r"\w+"] LiteralString[r"\w+"] then specific kinds of literal string can be "enforced" by static type checkers. Then IDEs could at the very least highlight that a string literal is not valid. I stress these are just examples, the goal is to have a way to tell a static type checker what the structure of a string literal has to be. """

2 2

Typing-sig January 2023