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

Any good way of typing a scikit-learn Bunch?
by Graham Wheeler 21 Aug '20

21 Aug '20

Hi all I have been looking at writing typings for sklearn and am wondering if there is a good solution for https://scikit-learn.org/stable/modules/generated/sklearn.utils.Bunch.html Clearly it can be typed as just the class itself; however, there are many examples with sklearn that start with loading a sample dataset, in which case the specific members are useful to specify. For example: from sklearn.datasets import load_iris iris = load_iris() X = iris.data y = iris.target NamedDictionary seems about the closest but its not ideal. Protocols might be another option. Wondering if there is a better solution. This might be useful at some point in doing dynamic typing of things like pandas DataFrames where columns could be treated in a similar way (e.g. in a live environment like a Jupyter notebook). Thanks Graham

2 2

PEP 604 ready for acceptance (Allow writing union types as X | Y)
by Guido van Rossum 14 Aug '20

14 Aug '20

I'm ready to pronounce PEP 604 as accepted: https://www.python.org/dev/peps/ pep-0604/ With the help of Maggie Moss the PEP has received some updates clarifying the specification; Maggie's implementation is also well under way. Unless there are objections here within the next 24 hours I will accept the PEP, and the feature will launch in Python 3.10. Thanks Philippe Prados for bringing this to PEP level and thanks to Maggie for her implementation work. -- --Guido van Rossum (python.org/~guido) *Pronouns: he/him **(why is my pronoun here?)* <http://feministing.com/2015/02/03/how-using-they-as-a-singular-pronoun-can-…>

4 5

PEP 612: Parameter Specification Variables Discussion Pt. II
by Mark Mendoza 11 Aug '20

11 Aug '20

Hi All, I want to start off by thanking everyone that gave feedback on the first round of review of PEP 612. Your feedback illuminated a lot of things that I think have made this PEP a lot better. Over the past few weeks I have had the time to rewrite much of that document to integrate all of that feedback. Notably, this included integrating `typing.type_variable_operators.Concatenate` to support decorators that modify a finite number of positional parameters. With that being said, I'd appreciate another round of feedback from all of you to determine whether this form of the PEP is ready to move on to the Steering Council. Thanks again! Mark Mendoza

4 12

Protocols for Modules?
by Saul Shanabrook 11 Aug '20

11 Aug '20

Does anyone know if there has been any existing discussion on providing an equivalent of `typing.Protocol` but for modules instead of classes? For example, a use case coming up in the numeric world is a function like `np.get_array_module(x)` which should return a a module that "behaves like" the base `numpy` module. See NEP 0037 for the details: https://numpy.org/neps/nep-0037-array-module.html#how-to-use-get-array-modu… Currently, this type of function isn't statically typed, but we are working to create a standard array API which would be some version of a slimmed down NumPy API. If we did provide a function like `get_array_module()` to return some module which implements, I am unclear how to type it currently. Should we type it as a protocol? Are modules considered instances of a protocol? Ideally, I could imagine wanting to write a module like this: ``` from typing_extensions import Protocol def arange(x: int) -> Array: ... class Array(Protocol): def __add__(self, Union[Array, int]) -> Array: ... ``` And then ideally we would be able to annotate a function like `get_array_module()` to say "You must return a module or object that has the `arange` function that returns an object that follow the Array protocol."

3 3

Tensor typing - next group call
by Matthew Rahtz 11 Aug '20

11 Aug '20

Hi everyone, Next week we'll be holding our next tensor typing meeting. WHEN? Monday 3rd August, 9:30am SF time. GCal link: https://calendar.google.com/event?action=TEMPLATE&tmeid=NzY5cXM1am5uNDNkMW1… WHERE? Google Meet. We'll post the link on the day itself. WHAT? 1. Status updates. What have folks been working on over the past month? 2. What should symbols mean? Jörg and I would like to make a second attempt at making the case that symbols should by default refer to semantic axis types (e.g. `Batch` => a batch-like axis) rather than actual shapes (`Batch` => a concrete value of '32'). We'll have a short presentation and then we'll open it up for discussion. 3. Other. Is there anything else folks would like to talk about? Cheers! Matthew

2 5

What is the intended use case for the typing.SuportsXyz protocols?
by Luciano Ramalho 02 Aug '20

02 Aug '20

I was excited to learn about SupportsInt, SupportsFloat, and SupportsComplex protocols decorated with @runtime_checkable because I thought they bridged the gap between ABCs and typing protocol classes, allowing consistent type checks by static tools and at runtime. However, I am unable to see how to use those classes in practice. For example, SupportsComplex: I understand at runtime the @runtime_checkable decorator merely checks whether __complex__ exists in the type, but that is not a good predictor of how to use a numeric value. Types that actually can be converted to complex fail the insinstance check with SupportsComplex. That's the case of built-in int and float, as well as NumPy integer and float types like float16 and uint8. On the other hand, SupportsInt suggests that I can convert a complex to int, but in fact the int and float types implement __complex__ only to provide a better error message, according to Guido van Rossum in an earlier thread here. >>> isinstance(1+0j, SupportsInt) True >>> int(1+0j) Traceback (most recent call last): ... TypeError: can't convert complex to int The issue with SupportsInt also happens with SupportsFloat. In addition, the way Mypy interprets these protocol classes is not the same as what we can see at runtime. Given the above, what are recommended use cases for the runtime checkable SupportsInt, SupportsFloat, and SupportsComplex? Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg

2 1

assigning a NoReturn function call
by Martin DeMello 01 Aug '20

01 Aug '20

Should the following be a type error? ``` def f() -> NoReturn while True: ... x = f() ``` Neither pytype nor mypy currently catch it. martin

2 3