Mailman 3 May 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 23 Dec '22

23 Dec '22

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?

16 34

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

Question about PEP 612
by Nathaniel J. Smith 22 Jun '20

22 Jun '20

I have some functions that from a typing perspective look like: def call_in_special_context(f, *args, **kwargs): # In reality, runs 'f' in a thread or something return f(*args, **kwargs) An example in the stdlib would be https://docs.python.org/3/library/contextvars.html#contextvars.Context.run Of course, right now, there's no good way to add types to this. But with PEP 612, it seems like we could write: Ps = ParameterSpecification("Ps") R = TypeVar("R") def call_in_special_context(f: Callable[Ps, R], *args: Ps.args, **kwargs, Ps.kwargs) -> R: ... None of the examples is the PEP actually look like this though – they all involve referencing Ps.args and Ps.kwargs inside the function/class scope that uses Ps, while here we need to reference them right in the same args list. So, first question: is the example above something that would be supported under PEP 612? (And if so, a suggestion would be to add some examples like that to the text :-).) Second question: there's also a convention that shows up in e.g. asyncio, of passing through *args, while reserving kwargs for the wrapper. For example: # https://docs.python.org/3/library/asyncio-eventloop.html#asyncio.loop.call_… def call_soon(self, callback, *args, context=None): ... In PEP 612 notation, this method has type: def call_soon(self, callback: Callable[Ps, Any], *args: Ps.args, context=None): But I think that this is *not* allowed by PEP 612, because "These operators can only be used together, as the annotated types for *args and **kwargs", and the 'def baz' example. So even with PEP 612, we still can't type loop.call_soon. Is that correct? Third question: suppose I have a function that captures some kwargs, but passes through unrecognized ones: def call_in_special_context(f, *args, **kwargs, special_kwarg): do_something_else_with(special_kwarg) return f(*args, **kwargs) In this case, you might expect to write: def call_in_special_context(f: Callable[Ps, R], *args: Ps.args, **kwargs, Ps.kwargs, special_kwarg: SomeType) -> R: The semantics would be that at call sites for call_in_special_context, the type checker would check that 'special_kwarg' matches the given type, and that all other kwargs are valid for 'f'. Is this legal/supported? Thanks! -n P.S.: I'm not subscribed to the list; trying out posting through the mailman 3 web interface thing. So if you could CC me on replies that would be helpful :-)

2 3

"auto" return type
by kshpitsa＠gmail.com 03 Jun '20

03 Jun '20

Per Guido Van Rossum's suggestion, I am re-posting what was initially opened as an issue at python/typing (https://github.com/python/typing/issues/727). I am unsure if this issue should go here or rather to mypy's tracker. I have looked through issues in both `typing` and `mypy` and couldn't find anything related. Consider the following code: ```py import typing as tp class A: x: int def f1() -> A: return A() def f2() -> tp.Any: return f1() x = f1() x.x = "" # [1] y = f2() y.x = "" # [2] ``` Upon checking with mypy, an expected `Incompatible types in assignment (expression has type "str", variable has type "int")` error is emited at [1], but not at [2]. This makes sense, as type of `y` is `Any`. However, e.g. [jedi](https://jedi.readthedocs.io/en/latest/) autocompletion library is smart enough to deduce that `f2() -> A`. While in the above degenerate example it would be trivial to just property annotate the `f2`, the real scenario has `A` and `f1` defined in some library, and `f2`, which does something more useful than just calling `f1` is defined in user-code. Specific class `A` is not intended to be directly instantiated by the user, moreover, it may be buried deeply inside module hierarchy, which may also change between library releases. My suggestion is to introduce `typing.Auto` which, when used in return type annotation, would instruct type checker (mypy or any other) to infer return type from the type of expression in return statement. In case of multiple return statements, the pragmatical approach would probably be to infer the base-most class, possibly issuing an error or a warning if types are completely unrelated. Another possibility is to optionally have mypy treat `typing.Any` return types in a manner suggested for the above-described `typing.Auto` but I suspect that this would be a breaking change. P.S. `typing.Auto` should also be usable within `typing.Tuple`. I am not sure whether it would be desirable to allow inference of tuple in cases when return type is annotated as `typing.Auto`.

6 6

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

The state of PEP 613 - Explicit Type Aliases in Python 3.9
by Mikhail Golubev 29 May '20

29 May '20

Hi there! I'm wondering about the current state of PEP 613 "Explicit Type Aliases". The document in "accepted" state, and it seems to me that it was even scheduled for Python 3.9 at some point. However now, as 3.9.0b1 is out, the name "TypeAlias" is not present in typing module. What's more, it also has been removed from typing.pyi in Typeshed lately. Mypy has no trackable plans of supporting it anytime soon either, at least judging by my question in the Gitter chat. Is "TypeAlias" still going to appear in 3.9 or at least be available via typing_extensions? Thanks!

3 7

pyanalyze, a newly public type checker
by Jelle Zijlstra 29 May '20

29 May '20

I just open sourced pyanalyze (https://github.com/quora/pyanalyze), a static analysis tool and type checker. The announcement post is in https://www.quora.com/q/quoraengineering/Static-analysis-at-Quora-and-pyana…. Pyanalyze was initially written as a static analysis tool specifically for checking some common patterns in our codebase at Quora, but we extended it to perform a subset of PEP 484 type checking. I hope the tool will be useful to others as well!

1 0

Help with explaining the value of typing.TypedDict
by Luciano Ramalho 20 May '20

20 May '20

I hope you're all well. I am writing the 2nd edition of Fluent Python and right now I am trying to wrap up a section on typing.TypedDict, but I am having a very hard time understanding its value in real world scenarios. PEP 589 acknowledges that JSON is a "canonical use case" for dicts used as records. But since the whole point of a TypedDict is to provide syntax for type hints, I can't find a connection or any benefit of using TypedDict with code that deals with JSON—where all the action is at runtime. All the examples in the PEP use literal dicts as values when assigning to variables annotated with a TypedDict type. If I annotate a function parameter with a TypedDict, and I am forced to spell out all the keys to provide a dict argument that can be type checked, I don't see why not use keyword arguments in the function definition in the first place... My testing shows that Mypy is unable to do much validation beyond assignment from dict displays or dict constructor calls with keyword arguments. More realistic use cases that I was able to imagine often need casts and don't perform any useful static checking. My future readers and I could really use more insight about real world use cases where TypedDict adds value. Thanks for any help! Cheers, Luciano -- Luciano Ramalho | Author of Fluent Python (O'Reilly, 2015) | http://shop.oreilly.com/product/0636920032519.do | Technical Principal at ThoughtWorks | Twitter: @ramalhoorg

3 2

Status of PEP 604 -- Complementary syntax for Union[]
by Luciano Ramalho 20 May '20

20 May '20

"PEP 604 -- Complementary syntax for Union[]" targets Python 3.9, but did not make into beta1 and is still draft. Is there a final decision on that PEP? 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

buffer protocol interim solution(s)?
by René Dudfield 19 May '20

19 May '20

Hi, to share data, a number of libraries use the buffer protocol(s)[0 <https://docs.python.org/3/c-api/buffer.html>]. There seems to be a python issue open [1 <https://bugs.python.org/issue27501>], and a typing issue open [2 <https://github.com/python/typing/issues/593>]. Anyone have better interim solution(s) that work cross-library? The given work-around in [2 <https://github.com/python/typing/issues/593>] doesn't really work in a number of cases: > Union[bytes, bytearray, memoryview] > > Consider if this would work with array.array, or <type 'numpy.ndarray'> or dozens of other libraries buffer protocol friendly types. As a concrete example, numpy is adding the ndarray to that Union using this [3 <https://github.com/numpy/numpy-stubs/blob/master/numpy-stubs/__init__.pyi#L…> ]: _BufferType = Union[ndarray, bytes, bytearray, memoryview] Whilst this supports ndarray, it doesn't scale to the full list of third party types supporting buffer protocol(s) [opencv, pygame, pillow, ...]. Every suggestion appreciated -- even the strangest, ugliest, most horrific of hacks. Thanks. cheers, [0] https://docs.python.org/3/c-api/buffer.html [1] https://bugs.python.org/issue27501 [2] https://github.com/python/typing/issues/593 [3] https://github.com/numpy/numpy-stubs/blob/master/numpy-stubs/__init__.pyi#L…

4 6

Typing-sig May 2020