[Epa095]

So, how does that relate to this quote from the article?

  >ty, on the other hand, follows a different mantra: the gradual guarantee. The principal idea is that in a well-typed program, removing a type annotation should not cause a type error. In other words: you shouldn’t need to add new types to working code to resolve type errors.

It seems like `ty`'s current behaviour is compatible with this, but changing it won't (unless it will just be impossible to type a list of different types).

[rtpg]

You could have a `list[int | str]` but then you need to check the type of the elements in the list on usage to see if they are `int` or `str` (if you are actually trying to put the elements into a place that requires an `int` or requires a `str` but wouldn't accept an `int | str`...).

If your code doesn't do that then your program isn't well typed according to Python's typing semantics... I think.

So you can have lists of multiple types, but then you get consequences from that in needing type guards.

Of course you still have stuff like `tuple[int, int, int, str]` to get more of the way there. Maybe one day we'll get `FixedList[int, int, int, str]`....

[_carljm]

There are ways to type invariant generics more precisely that still meet the gradual guarantee. E.g.:

  x = []  # list[Unknown]
  x.append(A())  # list[Unknown | A]
  takes_list_of_a_or_b(x)  # list[A | B]

We haven't decided yet if this is what we want to do, though. It's also possible that we may decide to compromise on the gradual guarantee in this area. It's not an ironclad rule for us, just something we're considering as a factor.