Mailman 3 January 2022 - Typing-sig

Opened and changed typing issues week 2022-W02
by Typing Bot 17 Jan '22

17 Jan '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: #241 Allow subclassing without supertyping opened by @dmoisset https://github.com/python/typing/issues/241 #996 TypeGuard type narrowing on returning False opened by @ikamensh https://github.com/python/typing/issues/996 #1000 ParamSpec: Allow only `P.args` opened by @cdce8p https://github.com/python/typing/issues/1000 --------------------------------------------------- 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

Proposal: Type evaluation functions
by Jelle Zijlstra 15 Jan '22

15 Jan '22

I recently implemented a new feature in pyanalyze that unlocks many things that aren't possible with the current type system and provides a simpler alternative for most use cases of overloads. The idea is that users can specify a special function, marked with the `@evaluated` decorator, written in a (very) restricted subset of Python, to indicate how a type checker should evaluate a function call. For example, this is an implementation of a simplified version of the `open()` builtin: @evaluated def open(mode: str): if is_of_type(mode, Literal["r", "w"]): return TextIO elif is_of_type(mode, Literal["rb", "wb"]): return BinaryIO else: return IO[Any] Compared to overloads, this is shorter (the real `open()` takes lots of other parameters, which have to be repeated with every overload), is easier to read (you don't have to stare at a series of overloads to find the difference), and gives the stub author more precise control over how the code is interpreted (overloads are underspecified). I wrote a detailed spec at https://github.com/quora/pyanalyze/blob/master/docs/type_evaluation.md, but here I'll just briefly cover a few more use cases. 1. Customized errors The specification includes a `show_error()` intrinsic that allows users to emit a specific error message. For example, we may want to warn about the deprecated `U` mode: @evaluated def open(mode: str): if is_of_type(mode, Literal["rU"]): show_error("The U open mode is deprecated", argument=mode) ... 2. Overlapping types Some type checkers implement custom checks for cases where two types do not overlap but are compared. Type evaluation functions provide a way to do this in the stub itself: @evaluated def safe_contains(elt: T1, container: Container[T2]) -> bool: if not is_of_type(elt, T2) and not is_of_type(container, Container[T1]): show_error("Element cannot be a member of container") lst: List[int] safe_contains("x", lst) # error safe_contains(True, lst) # ok (bool is a subclass of int) safe_contains(object(), lst) # ok (List[int] is a subclass of Container[object]) 3. Detecting invalid combinations of arguments `open()` takes an `encoding` argument that must be None if the file is opened in binary mode. But the current typeshed overloads ( https://github.com/python/typeshed/blob/f42de016b8443bea012d06d02c88d41e0bd…) do not catch this case, because `open(..., "rb", encoding="x")` matches the fallback overload with `mode: str`. A full implementation of `open()` is in the pyanalyze test suite: https://github.com/quora/pyanalyze/blob/234625d88aa4c0b2f9ffc76cc9a0ec7b3f0… . I'd love to hear any feedback: Is this worth pursuing as a PEP? Are there more use cases that could be covered? Should the spec be changed?

4 8

How to type a deprecated argument?
by Sebastian Berg 14 Jan '22

14 Jan '22

Hi all, a (hopefully) very brief question: How would you type a deprecated API, in particular a kwarg that is in the process of renaming. [1] In such cases NumPy currently makes the stubs "live in the future": They indicate that the old name is not a valid argument. [2] Now there is a request that the stubs should accept both until the deprecation is finalized. Is that the "obviously" preferred option or is it reasonable to ask users to just use `# type: ignore `? I am more than happy if the answer is just a shrug ;). Cheers, Sebastian [1] I found some discussions about supporting a Deprecated type-hint, but not on a clear preference here. [2] This may partially come from the fact that we have API that should never be used and I think some of that is intentionally not typed.

2 1

Re: RFC on Arbitrary Literal Strings PEP
by Arie Bovenberg 14 Jan '22

14 Jan '22

Hi all, The motivation in the PEP mentions SQL and shell scripts, but logging may also be a potential use-case to mention. Logging does string formatting. So, if you feed it an arbitrary string, you can get into trouble: logger.info(f'look: {untrusted_string}', some_dict) # DANGER if untrusted_string = %(somekey)999999999s IMHO this seemed like a good place to make use of Literal[str]. I’ve opened a discussion at https://bugs.python.org/issue46200, and would be interested to hear some opinions from this crowd.

1 0

Next tensor typing meeting: Monday 17th of January?
by Matthew Rahtz 14 Jan '22

14 Jan '22

Hey everyone, Happy new year! Hope everyone managed to get some proper rest and relaxation over the holidays. We'd tentatively set the 17 of January as the date for our next tensor typing meeting, but once again I'm not sure we have anything to discuss. Does anyone have something they'd like to present or talk about? In terms of progress updates from our end: we've resubmitted PEP 646 to the steering council, and finished a first draft of the CPython implementation: https://github.com/python/cpython/pull/30398 So now we're mainly waiting on word from the steering council about whether they're happy with our revisions. Thanks! Matthew

2 2

Opened and changed typing issues week 2022-W01
by Typing Bot 10 Jan '22

10 Jan '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 opened last week: #1009 ParamSpec: No support for adding keyword-only argument opened by @ItsDrike https://github.com/python/typing/issues/1009 --------------------------------------------------- The following issues and pull requests were updated last week: #182 Define a JSON type opened by @brettcannon https://github.com/python/typing/issues/182 #213 Introduce an Intersection opened by @ilevkivskyi https://github.com/python/typing/issues/213 #801 Introduce a Not type opened by @antonagestam https://github.com/python/typing/issues/801 #996 TypeGuard type narrowing on returning False opened by @ikamensh https://github.com/python/typing/issues/996 #1000 ParamSpec: Allow only `P.args` opened by @cdce8p https://github.com/python/typing/issues/1000 --------------------------------------------------- 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

`typing.get_type_hints` and implicit `Optional`
by Никита Соболев 09 Jan '22

09 Jan '22

Hi! I am posting this to get additional feedback on a proposed change to CPython. I propose removing the addition of implicit `Optional` type for cases like `def some(arg: int = None):`. Right now `get_type_hints(some)` will return `{'arg': Optional[int]}`. After https://github.com/python/cpython/pull/30304 it will return just `{'arg': int}`. Why? 1. This behavior has bugs. Like the one described in https://bugs.python.org/issue46195 2. Because PEP484 was changed: https://github.com/python/typing/issues/275 and https://github.com/python/peps/pull/689 Does anyone rely heavily on this behavior? Maybe we need to support some kind of optional bool argument like `add_implicit_optional` in `get_type_hints` for backward compat? Feedback on the PR is welcome 🙂 Link: https://github.com/python/cpython/pull/30304 Best, Nikita Sobolev

1 0

Please consider a decorator in typing to mark base class methods whose overrides must call super
by Neil Girdhar 07 Jan '22

07 Jan '22

Not calling super on __init__ is a common source of bugs. So much so, that some base classes explicitly check for it (e.g., https://github.com/deepmind/dm-haiku/blob/main/haiku/_src/module.py#L142). Besides the specific problem with __init__, this is a general pattern that some methods overrides must call super. I was wondering if we could get a a decorator in typing to mark base class methods whose overrides must call super. This suggestion is motivated by an issue I saw on pyright: https://github.com/microsoft/pyright/issues/2789 The basic idea would be something like this: from typing import augmentable class C: @aumentable def f(self, ...) -> None: ... class D(C): def f(self, ...) -> None: # Error: aumentable method override doesn't call super. print(10) By default, methods like __init__, __init_subclass__, __enter__, and __exit__ (any others?) should be "augmentable".

4 4

New Trove Classifier for stub-only distributions
by Ethan Smith 03 Jan '22

03 Jan '22

Hey all, Happy New Year! Just wanted to spread the word that there is now a new trove classifier <https://github.com/pypa/trove-classifiers/pull/88> for stub-only distributions, "Typing :: Stubs Only". The difference between "Typing :: Typed" and "Typing :: Stubs Only" is that "Typing :: Typed" should be used for distributions with runtime code, whereas "Typing :: Stubs Only" should be used for distributions that provide "*-stubs" packages for another package. I'm not sure what the process is to have this deployed in Warehouse, so I don't know when it will be usable. Best, Ethan

2 1

Thoughts on a NotType?
by James H-B 03 Jan '22

03 Jan '22

Hi, I'd like to write a PEP for a new typing construct: NotType which, would be equivalent to any type but x. There has been an issue open on the typing repo for quite some time about this (https://github.com/python/typing/issues/801). After the recent-ish proposal for an IntersectionType, this would be a nice-to-have feature as it would complete the set theory operations for typed Python. I'd also like to propose implementing type.__invert__ to make this work, so it has built-in syntax like intersection and union as this is the closest thing to a not operator. Usecases: Something that takes any non-empty string ```py def fn(x: str & ~Literal[""]): ... ``` This also has nice integration with PEP 675 where the type of a Literal str is important. If you’d want to call this from any str you’d need a type guard. ```py def guard(x: str) -> TypeGuard[str & ~Literal[“”]]: return isinstance(x, str) and x != “” # or maybe bool(x) although this is probably much harder to implement ``` Something that takes any value but None ```py def fn(x: ~Literal[None]): ... ``` Something that requires not an integer ```py def not_an_int(x: Any) -> TypeGuard[~int]: ... ``` This also allows for narrowing in the negative case which is another requested feature (https://github.com/python/typing/issues/926)  ```py @overload def is_none(value: None) -> Literal[True]: ... @overload def is_none(value: ~Literal[None]) -> Literal[False]: ... def is_none(value: Any) -> bool: return value is None def func(value: Optional[str]): if is_none(value): reveal_type(value) # None else: reveal_type(value) # str  ``` Currently this isn’t the case  ```py def is_none(value: Any) -> TypeGuard[None]: return value is None def func(value: Optional[str]): if is_none(value): reveal_type(value) # None else: reveal_type(value) # str | None ``` Overloading operators more correctly, more easily ```py @overload def __eq__(self, other: ~Self) -> Literal[False]: ... @overload def __eq__(self, other: Self) -> bool: ... def __eq__(self, other: object) -> bool: return isinstance(other, self.__class__) and ... ``` Something fun ```py reveal_type(~~str) # str ``` A few questions: Can you see any issues here? Do you have ideas for use cases I haven't thought of? Does anybody want to be a co-author on this?

7 12

2022

2021

2020

2019

2018

Typing-sig January 2022