Mailman 3 November 2022 - Typing-sig

Annotating `self` with a protocol?
by Thomas Kehrenberg 22 Nov '22

22 Nov '22

I have noticed that mypy and pyright have this (undocumented?) feature where you can annotate `self` in a method with a protocol: from dataclasses import dataclass from typing import Protocol class HasX(Protocol): x: int class Base: def double_x(self: HasX) -> int: return 2 * self.x @dataclass class ChildCorrect(Base): x: int ChildCorrect(3).double_x() # OK @dataclass class ChildIncorrect(Base): y: int ChildIncorrect(3).double_x() # err: not compatible with HasX Note that `HasX` isn't anywhere in the base classes of `Base`. My first question is whether this feature is documented somewhere. And my second question is whether this could also take into account methods defined in the actual class. So, for example, if I change the above example to class HasX(Protocol): x: int class Base: def z(self) -> int: return 4 def double_x_plus_z(self: HasX) -> int: return 2 * self.x + self.z() # type-check error then the type checker complains about `self.z()` because `HasX` doesn't have this method. However, it seems to me that any possible type for `self` will have this method, because `Base` defines it right there. So, shouldn't this type-check? Cheers, Thomas

3 2

PEP 646 – Variadic Generics multiple matching variants
by andrey.matveev.mano＠gmail.com 22 Nov '22

22 Nov '22

Have this example: ``` from __future__ import annotations from typing import Generic from typing import TypeVar from typing import TypeVarTuple Shape = TypeVarTuple("Shape") T = TypeVar("T") T1 = TypeVar("T1") class Array(Generic[*Shape]): ... y: Array[int, *tuple[float, ...], int, str] = Array() def expect_variadic_array(x: Array[int, T, *Shape, T1]) -> Array[*Shape, T, T1]: ... expr = expect_variadic_array(y) which type is expected for expr? ``` Here we can assign: ``` int -> int T -> int (*float empty) *Shape -> empty T1 -> str so return Array[int, str] ``` or ``` int -> int T -> float *Shape -> int T1 -> str ``` so T can be either int or float and *Shape can be either () or (int, float*)

3 2

Opened and changed typing issues week 2022-W46
by Typing Bot 21 Nov '22

21 Nov '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 #689 Literal for sentinel values opened by @srittau https://github.com/python/typing/issues/689 #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: Typing Meetup
by S Pradeep Kumar 16 Nov '22

16 Nov '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 51

Opened and changed typing issues week 2022-W45
by Typing Bot 14 Nov '22

14 Nov '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 #1160 Allow `float("inf")` and `float("-inf")` in literals opened by @antonagestam https://github.com/python/typing/issues/1160 --------------------------------------------------- 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

Draft PEP for Improved Type Parameter Syntax
by Eric Traut 08 Nov '22

08 Nov '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

16 51

Typing objects in interdependent modules
by TobiasHT 08 Nov '22

08 Nov '22

The title of the issue might be cryptic, but here's what I was trying to mean. I have two modules located in the same subpackage, something like this: ./objects /message.py /chat.py message.py has functions that take in objects from chat.py as parameters and so does message.py. I tried to import objects from message.py import chat.py to use for type annotations and also from chat.py to message.py for the same reason but I get circular import errors. Is there a way to create types for these objects that can still be used by the type checker to track the actual objects without importing the objects from either class? I'm thinking of creating a separate module called types and put the types there, but I can't figure out how to map the types I'll create to the objects in those two files so that they can be used without circular import errors. Perhaps if there's some runtime check that can be done, I'm not so sure.

3 3

Opened and changed typing issues week 2022-W44
by Typing Bot 07 Nov '22

07 Nov '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: #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

Defaults for TypeVar-likes
by James H-B 04 Nov '22

04 Nov '22

I've been toying with the idea of writting a PEP for this long requested feature (https://github.com/python/typing/issues/307). I've got a preliminary draft of it with the motivation and a specification for the feature. In short features like ```py T = TypeVar("T", default=int) # This means that if no type is specified T = int @dataclass class Box(Generic[T]): value: T | None = None reveal_type(Box()) # type is Box[int] reveal_type(Box(value="Hello World!")) # type is Box[str] ``` would be supported as would ```py YieldT = TypeVar("YieldT") SendT = TypeVar("SendT", default=None) ReturnT = TypeVar("ReturnT", default=None) class Generator(Generic[YieldT, SendT, ReturnT]): ... Generator[int] == Generator[int, None] == Generator[int, None, None] ``` Feedback and any questions on this would be very appreciated. https://gist.github.com/Gobot1234/8c9bfe8eb88f5ad42bf69b6f118033a7 Thanks, James H-B.

8 20

Idea: improving the type guard to be human readable
by Job Veldhuis 03 Nov '22

03 Nov '22

I would like to propose a change to type guards, in order to make using them in code more readable. However, I am unsure how achievable this added functionality would be: # Specification I would like to have type guards as readable as human text. Currently we use type guards in the following manner: ``` def is_list_of_str(value: list[object]) -> TypeGuard[list[str]]: return all(isinstance(x, str) for x in value) ``` However, this whole TypeGuard with nested syntax isn't really that readable, is it? In TypeScript, I think this problem was solved in a more beautiful way. I would like to propose to use the same syntax as TypeScript for user defined type guards: ``` def is_list_of_str(value: list[object]) -> value is list[str]: return all(isinstance(x, str) for x in value) ``` Since this might not be achievable, because value is not defined at the moment of statically typing, we might want to do something along the lines of either: ``` def is_list_of_str(value: list[object]) -> "value" is list[str]: return all(isinstance(x, str) for x in value) def is_list_of_str(value: list[object]) -> "value is list[str]": return all(isinstance(x, str) for x in value) ``` My preference would be the first one of the above examples, since this combines the readability with the current way used to type hint variables that may be defined later. Please let me know whether or not you think this is worth pursuing, as well as your general thoughts on the subject. - Job

2 1

Typing-sig November 2022