Mailman 3 April 2020 - Typing-sig

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

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

Explicit Type Aliases
by Shannon Zhu 17 Aug '22

17 Aug '22

Hi everyone, I’d like to continue the discussion from our last typing summit on explicit type aliases. A quick summary of the current state and the proposal -- Current state: ``` from typing import List x = List[int] # considered a type alias y : Type[List[int]] = List[int] # considered an expression z : Any # considered a type alias z : x = [] # fine z : y = [] # invalid type error ``` Proposal (with explicit aliases): ``` from typing import List, TypeAlias x = TypeAlias[List[int]] # considered a type alias y = List[int] # considered an expression z : Any # considered an expression z = TypeAlias[Any] # considered a type alias reveal_type(x) # Type[List[int]] reveal_type(y) # Any (return type of __getitem__) z : x = [] # fine z : y = [] # invalid type error ``` Some of the benefits we’re hoping to gain from explicit type aliases: * Clearly distinguish between an unannotated global assignment and a type alias, especially when parsing forward-referencing string annotations. * Avoid the confusing case of type aliases in which some part of the type is invalid or undefined. This would facilitate warnings on invalid types at the alias definition rather than later on when the alias is used. * Make valid and invalid types more intuitive to Python programmers by shifting from delineation of non-aliases with a meta annotation toward delineation of aliases with `TypeAlias`. * Remove special treatment of values annotated as `Any`, which currently break all type aliasing rules. This will also allow us to clean up some of the distinctions we maintain between unannotated values and explicit Anys. Note: We also considered denoting the alias as an annotation (e.g. `x: TypeAlias = int`) as an alternative to the syntax above. I’m interested to hear your thoughts and suggestions on making type aliasing explicit going forward – we’d like to start implementing a version of this in Pyre soon! Shannon

7 10

Bay Area Typing Meetup 9/20
by Dominik Gabi 01 Jun '20

01 Jun '20

Jukka and Ivan will be visiting the Bay Area in September and we'd like to organize another meetup. Here are the proposed (tentative) logistics: Date: Friday, Sept. 20 Time: 1pm - 5pm Location: Facebook in Menlo Park (building and room TBD) So far Ivan, Jukka, Guido, Rebecca, Martin (?), and myself have committed to attending. I'm also volunteering the rest of the Pyre team. Please let us know in advance if you plan on attending so that we can book an adequately sized room. Also now's the time to think about topics to discuss or presentations you want to give. – Dominik

4 3

Do stubs have to be valid Python?
by Graham Wheeler 28 Apr '20

28 Apr '20

Hi all I'm guessing the answer to my question in the subject line is "yes", but I'm hoping its "not necessarily". I'm working on stubs for Pandas. Pandas Series have a bunch of methods for which there is an "in place" argument. If True, the method will return None; if False, it will return a new DataFrame. The way I thought of trying to handle this is by doing something like this: @overload def replace(self, to_replace: Optional[Any] = ..., value: Optional[Any] = ..., *inplace: Literal[True]*, limit: Optional[int] = ..., regex: _Regex = ..., method: _str = ...) -> None: ... @overload def replace(self, to_replace: Optional[Any] = ..., value: Optional[Any] = ...,* inplace: Optional[Literal[False]] = ...*, limit: Optional[int] = ..., regex: _Regex = ..., method: _str = ...) -> DataFrame: .. The problem is that in the first case I am making the optional argument mandatory, and it lies in the middle of other optional arguments. I don't want to move it positionally because there is plenty of existing code out there that would then break. My guess is that this is not okay, but is there an alternative solution? Thanks Graham

3 4

Fully typed `functools.partial`
by Никита Соболев 18 Apr '20

18 Apr '20

Hello everyone! Recently I was curious about whether it is possible to create a fully typed `functools.partial` version. Because currently only return type is taken into account. So, I came up with the mypy plugin to type all the callable parameters during the partial application process and the final call. It works pretty well! Source: https://github.com/dry-python/returns/blob/master/returns/curry.py#L7 Plugin: https://github.com/dry-python/returns/blob/master/returns/contrib/mypy/_cur… Tests: https://github.com/dry-python/returns/tree/master/typesafety/test_curry I thought that mypy team might be interested in porting this (or similar) solution into the core. I would also be happy to receive any feedback on the code itself or the solution in general. Thanks a lot for building mypy, it is awesome! Best, Nikita Sobolev https://github.com/sobolevn

3 4