It is a silly type for a function to return, because you have three levels of data structure nesting, with not one bit of information about the meaning of any of the values except their types. If I call your function and then do result[1][2], what does that mean?

This is exactly the kind of situation where you're supposed to use a named tuple or a data class to make it clear what's what.

With tuples inside of lists, you usually unpack them to variables in a for loop.

Named tuples are just immutable classes with slots. Unless you want to slow your code down considerably, it's best to avoid them.

As of Python 3.10, you can use `T | U` instead of Union.

Starting from 3.8 (I think), you can also directly use dict[T, U] and list[T] rather than having to import Dict and List.

I would rather see work done on something more useful than new syntax for typing.

I am amazed at how much time some devs will waste on trying to figure out type annotations, at the expense of actual work time.

Learning any new syntax, feature, etc takes time. IME learning type annotations can pay major dividends. For example, I wrote some type-annotated code the other day and mypy pointed out a couple places where I was passing the wrong type, which saved me from having to fix those bugs later, thus saving time for "actual work."

There is a recurring cost to complex type annotations and that is that every single developer working on that repo (could be thousands) has to unravel the complex types, their aliases and the instance objects to modify any code.

This as opposed to a legitimate type system where complex types are classes themselves which don't need unraveling. There is no need to alias a type and there is no need to maintain separate complexities for the object and the type.

I agree that complexity could be an issue with Python's typing, which has some flaws, although it's been improving.

Type aliases are okay if they're not overly complex, having used them in Python and other languages to good effect, e.g. to avoid duplication or for clarity.

I'd suggest using type annotations where it's not overly onerous--which is probably most places--to get the benefits without much effort but perhaps avoid them or use simplified types where it's too complex.

I also agree that there are places where typing is unnecessary and doesn't add much value, such as in certain scripts.

Like many things in programming, it's all about finding the right trade-offs.

yeah it speaks to your ability to create code people can understand, that doesn't change with types, they just illuminate it

I, too, can write code that everyone understands! Behold it's beauty:

  Union[List[Tuple[Tuple[str, int, str], Tuple[int, float, float]]], Iterator[Tuple[Tuple[str, int, str], Tuple[int, float, float]]]]

/s