Mailman 3 - Typing-sig

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

Opened and changed typing issues week 2021-W52
by Typing Bot 03 Jan '22

03 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: #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 --------------------------------------------------- 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 #548 Higher-Kinded TypeVars opened by @tek https://github.com/python/typing/issues/548 #593 Buffer protocol types opened by @srittau https://github.com/python/typing/issues/593 #985 Make `builtins.property` generic opened by @sobolevn https://github.com/python/typing/issues/985 --------------------------------------------------- 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

Opened and changed typing issues week 2021-W51
by Typing Bot 27 Dec '21

27 Dec '21

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: #256 Possible to distinguish between Sequence[str]/Iterable[str] and str? opened by @jtatum https://github.com/python/typing/issues/256 #548 Higher-Kinded TypeVars opened by @tek https://github.com/python/typing/issues/548 #985 Make `builtins.property` generic opened by @sobolevn https://github.com/python/typing/issues/985 --------------------------------------------------- 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

Removing `async` keyword form PEP 677
by Steven Troxler 24 Dec '21

24 Dec '21

Pradeep, Guido and I are leaning toward removing the `async` part of PEP 677. There are several reasons: - If we leave `async` in, then `async (int) -> bool` and `(int) -> Awaitable[bool]` are the same - This violates that there should only be one obvious way to do things - It also might lead to a mismatch between written types and the errors returned by type checkers, leading to unnecessary confusion - It looks like < 5% of callable types return Awaitable anyway - It has explicitly been brought up in python-dev as unnecessary complexity, and we largely agree with this criticism. I wanted to float the idea of cutting `async` here first since so many folks from this thread contributed to the proposal in PEP 677. If there's no strong opposition, I'll probably remove it after the holidays. Cheers, - Steven

8 15

Re: Thoughts on a NotType?
by Anton Agestam 24 Dec '21

24 Dec '21

(Hoping I figured out how to reply in the thread now... ) Yes, sorry for the cryptic message but it looks like you got it right. The example isn't impressive but just like Steven is saying the value comes in larger applications. In a web application for instance only the parsing layer will have to deal with the runtime validation of the type. The business logic and database layers can use static type checking to make sure only the narrowed value is allowed. So it's kind of like a NewType plus an "instantiation predicate" (I'm failing to find the correct term, nothing is actually instantiated). I thought it's relevant here since I imagine a NotType would also have to rely a lot on runtime narrowing. If a downstream API takes Sequence & Not[str] and we have a Sequence available, we'd have to narrow it with something like assert not isinstance(..., str).

1 0

Re: Thoughts on a NotType?
by Anton Agestam 24 Dec '21

24 Dec '21

FWIW, I believe usecases like "sequence & not str" can be implemented with phantom-types, which I think alleviates a lot of the headaches that Eric brought up.

3 6

Should `Union[X, NoReturn]` be allowed?
by Tushar Sadhwani 23 Dec '21

23 Dec '21

PEP 484 says "Static type checkers will ensure that functions annotated as returning NoReturn truly never return, either implicitly or explicitly" But, currently, I can do this: def f(num: int | float) -> int | NoReturn: if isinstance(num, float): sys.exit() return num Even though the return type of this function is always `int`. Using `int | NoReturn` somewhat makes sense if you have overrides like this: @override def f(num: int) -> int @override def f(num: float) -> NoReturn But I don't think it still makes sense logically, as in "this function returns NoReturn, Sometimes" feels wrong. My question: Should `NoReturn` be allowed inside unions? OR should the type checker not allow that.

1 0

Concatenate with non-generic ParamSpec
by layday 23 Dec '21

23 Dec '21

`Concatenate` is useful in a non-generic context, to define a callable which takes certain arguments, followed by varargs. For example: from collections.abc import Callable from typing import Concatenate, ParamSpec P = ParamSpec("P") SomeCallableType = Callable[Concatenate[int, P], None] class Foo: some_callable: SomeCallableType[P] But type checkers will generate an error, e.g that `P` is unbound (mypy) or that it's meaningless (Pyright). Would there by any interest in allowing `ParamSpec` to stand alone in `Concatenate[int, P]` for varargs that don't need to be captured? PEP 612 contains this sole example of a (seemingly valid) solitarily `ParamSpec` in `Concatenate`: def expects_int_first(x: Callable[Concatenate[int, P], int]) -> None: ... Was it overlooked or did implementers believe it shouldn't be allowed? Best D Sent with ProtonMail Secure Email.

3 3