Mailman 3 December 2021 - Typing-sig

Opened and changed typing issues week 2021-W51
by Typing Bot Dec. 27, 2021

Dec. 27, 2021

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 Dec. 24, 2021

Dec. 24, 2021

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 Dec. 24, 2021

Dec. 24, 2021

(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 Dec. 24, 2021

Dec. 24, 2021

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 Dec. 23, 2021

Dec. 23, 2021

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 Dec. 23, 2021

Dec. 23, 2021

`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

Defining special forms in terms of `Annotated`
by val tron Dec. 23, 2021

Dec. 23, 2021

`Annotated` [1] was introduced to standardize annotations (beyond just types) and make it possible for static analyses to be written more independently of each other. However I see new type annotations [2] [3] that don't use the `Annotated` mechanism and so would need to be handled as special cases by anyone writing a static analysis, as is currently the case with Final, ClassVar, NewType, Any [4]. We should try to keep special forms to a minimum, if possible, by defining/rewriting them in terms of `Annotated`. For example: ``` Final[T] := Annotated[T, Final] ClassVar[T] := Annotated[T, ClassVar] Any := Annotated[object, AllowEverything] # that's more or less what `Any` means (UserId = NewType('UserId', int)) := (UserId: Annotated[..., NewType('UserId')] = int) TypeAlias := Annotated[..., TypeAlias] Required[T] := Annotated[T, Required] ``` Shortcuts for common patterns can still be provided (using `Annotated` + generics), but the goal is that consumers of annotations should only have to deal with `Annotated[<type>, <list of other annotations>]` instead of `Some[Nested[Form[<type>]]]`. [1] https://python.org/dev/peps/pep-0593 [2] https://python.org/dev/peps/pep-0613 [3] https://python.org/dev/peps/pep-0655 [4] While going through the docs to make this list I found `NoReturn` as well, which should be defined as `Union[]` (aka "empty" or "bottom"), but that's not related to `Annotated`.

3 2

Callable syntax: Unions in return position
by Steven Troxler Dec. 22, 2021

Dec. 22, 2021

In a different typing-sig thread [1] about deprecating typing.Union, a question came up about `|` vs `->` for callable types Since it's really a PEP677 question I thought I'd start a separate thread. Currently PEP 677 says that `|` binds tighter, so that ``` (int, str) -> bool | None ``` is a callable returning an optional `bool`, rather than an optional callable returning a `bool. Our reasons for having `|` bind tighter have to do with consistency: - `|` already binds more tightly in function signatures - e.g. `def f() -> int | None: ...` returns an optional int, with no parentheses needed - existing languages like TypeScript with both `|` and arrow types do this Another consideration, besides consistency, is to look at these questions is by looking at the most common use case. Pradeep did some analysis and it actually turns out that an optional callable is more common than returning an optional or union: - 330 functions take an Optional[Callable] argument - This is super common mainly because callbacks often modify "default" behavior, and using None as the default is a standard idiom - Only 12 return unions and 25 return optionals As a result, we have a dilemma in that consistency points one way (`|` should bind tighter) and use case metrics the other way. My personal views are that: - in this case, consistency is more important even if metrics point the other way - in particular it seems unacceptable to have `|` bind more tightly in signatures / less tightly in callable types - the problem is easily handled in many codebases with linters and autoformatters - we could and maybe should insert language explicitly encouraging parentheses if we think this will become a major problem - I'm also not *too* worried about user experience in any case because it will get caught statically: - any errors from mixing up precedence will happen in type checking rather than at runtime, and often display in-editor - as a result, it seems to me like most users will shrug and add parentheses without much confusion - and I think it would be very rare for a precedence mixup to go undetected and cause an application to fail But we'd like to get a chance to hear your thoughts before we decide whether / how to best address this in the PEP. ------ [1] typing.Union deprecation theread https://mail.python.org/archives/list/typing-sig@python.org/thread/TW5M6XDN…

4 7

Should typing.Union be deprecated?
by Paul Bryan Dec. 21, 2021

Dec. 21, 2021

Now that Python 3.10 is in Arch Linux, I'm starting to kick the tires on its typing changes. Now that types.Union is in place for the `type | type` construct, I'm wondering if there's a future for typing.Union (and typing.Optional), or if it should be flagged as deprecated. Thoughts?

16 37

Opened and changed typing issues week 2021-W50
by Typing Bot Dec. 20, 2021

Dec. 20, 2021

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: #985 Make `builtins.property` generic opened by @sobolevn https://github.com/python/typing/issues/985 --------------------------------------------------- The following issues and pull requests were updated last week: #548 Higher-Kinded TypeVars opened by @tek https://github.com/python/typing/issues/548 #895 Should there be a `Numeric` type? opened by @alexreg https://github.com/python/typing/issues/895 #922 non-final frozen attributes (was: Improved read-only attributes of Protocol) opened by @ariebovenberg https://github.com/python/typing/issues/922 #926 Change PEP 647 to allow for narrowing in the negative case opened by @Zomatree https://github.com/python/typing/issues/926 --------------------------------------------------- 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