On Sat, Mar 14, 2020 at 1:03 PM Noah Peter May <me@noahpmay.dev> wrote:
Yeah, PEP 585 should definitely get pushed through! That would be super useful all around.

Besides that, I think PEP 563 would mitigate most of the slowdown at runtime introduced by 604. The only exceptions would be explicit like assigning variables to types (int_list = List[int]) or dataclasses and the like.

Type aliases like that are actually pretty common in large code bases (which are the primary target for static typing in general) and it's pretty important not to have to suddenly switch from list[int] to List[int] there.

----

And a sidenote on 563: wouldn't this pep allow us to use basic annotations without having to import typing (technically speaking)? For all PEP 563 cares, this would be valid code:

var1: List[Tuple[int, str]] # List and Tuple not imported
my_var: Definitely_not_a_type = 42

AFAIK none of the existing static type checkers support that, and it would be a fairly big change to make it work -- and it would probably have to be coordinated through typeshed. I would really rather not have to do this.
 
Maybe a complementary PEP to 563 would make it standard to use unresolved type annots without importing the typing module. Unless you have something that uses annotations at runtime, I don't see a need to import the library at all. Static analysis tools would import typing themselves to do their magic.

It seems a simple enough idea. But unless you are a current contributor to one of the existing static type checkers I don't think you have the context to know how disruptive this would be.
 
But that is also, unfortunately, pushing more work onto them and other tools like autocomplete...

Right.

--
--Guido van Rossum (python.org/~guido)