tuple literal types

[DetachHead]

foo: (int, str)

[divaltor]

I think it's better to stick with PEP standard of typings declaration, because at some moment you can switch to new type checker or use mypy, for example, which couldn't understand such syntax, IMO

[DetachHead]

i'm going to put all non-standard features behind an allowNonStandardFeatures option i think, that way users can decide for themselves

[KotlinIsland]

There is also the scenario of banning non-pep behaviour for public API/evaluated extressions

[DetachHead]

we need to also account for their usage inside generics, because these two mean the same thing at runtime:

foo: list[(int, str)]
bar: list[int, str]

the only way to make it work is to add a trailing comma, which looks god awful:

foo: list[(int, str),]

so i think the only possible solutions are either:

1. ban tuple literal syntax inside generics
2. enforce __future__.annotations and just treat list[(int, str)] as a list of tuples, and list[int, str] as an invalid type

[KotlinIsland]

additionally, generic constraints are now provided with a tuple:

def f[T: (int, str)](t: T): ...

[DetachHead]

i dont think this is feasible unless we can come up with a solution to both of those problems

[KotlinIsland]

with the ones in generics, just don't allow it for now, until a more comprehensive solution can be built. for constraints, just take it as a constraint.

[DetachHead]

i don't like the idea of changing the syntax to something that means something else in certain contexts, and is only sometimes allowed. this will just add more confusion to the type system which is already a complete mess