There's actually another issue with ForwardRefs. They don't work in the REPL. So this will work when run as a module:

  def foo() -> "Bar":
     return Bar()

However, all of these issues should be fixed in 3.14 with PEP649 and PEP749:

> At compile time, if the definition of an object includes annotations, the Python compiler will write the expressions computing the annotations into its own function. When run, the function will return the annotations dict. The Python compiler then stores a reference to this function in __annotate__ on the object.

> This mechanism delays the evaluation of annotations expressions until the annotations are examined, which solves many circular reference problems.

> that isn't going to work if you try to use type hints in python because you're going to end up with a cyclic import. More specifically, you don't need cyclic imports in Python normally because you don't need the types, but you HAVE to import the types to add type hints, which introduces cyclic imports JUST to add type hints.

Yes, `typing.TYPE_CHECKING` is there so that you can conditionally avoid imports that are only needed for type annotations. And yes, importing modules can have side effects and performance implications. And yes, I agree it's ugly as sin.

But Python does in fact allow for cyclic imports — as long as you're importing the modules themselves, rather than importing names `from` those modules. (By the way, the syntax is the other way around: `from ... import ...`.)

https://stackoverflow.com/questions/744373/

This is trivial to solve by simply not having circular imports. Place the types in one file and the usage of it in others.

This has many benefits, like forcing you to think about the dependencies and layers of your architecture. Here is a good read about why, from F# that has the same limitation https://fsharpforfunandprofit.com/posts/cyclic-dependencies/

As others already mentioned, importing __annotations__ also works.

> If you have a cyclic reference between two files,

Don't have cyclic references between two files.

It makes testing very difficult, because in order to test something in one file, you need to import the other one, even though it has nothing to do with the test.

It makes the code more difficult to read, because you're importing these two files in places where you only need one of them, and it's not immediately clear why you're importing the second one. And it's not very satisfying to learn that you you're importing the second one not because you "need" it but because the circular import forces you to do so.

Every single time you have cyclic references, what you really have are two pieces of code that rely on a third piece of code, so take that third piece, separate it out, and have the first two pieces of code depend on the third piece.

Now things can be tested, imports can be made sanely, and life is much better.

Agreed that this "hack" is very ugly!

On the other hand, I tend to take it as a hint that I should look at my module structure, and see if I can avoid the cyclic import (even if before adding type hints there was no error, there still already was a "semantic dependency"...)

You're actually missing the benefit of this. It's actually a feature.

With python, because types are part of python itself, they can thus be programmable. You can create a function that takes in a typehint and returns a new typehint. This is legal python. For example below I create a function that dynamically returns a type that restricts a Dictionary to have a specific key and value.

   from typing import TypedDict

   def make_typed_dict(name: str, required_key: str, value_type: type):
       return TypedDict(name, {required_key: value_type, id: int})

   # Example
   UserDict = make_typed_dict("UserDict", "username", str)

   def foo(data: UserDict):
       print(data["username"])

In practice, using types to prove programs to be valid in place of testing is actually a bit too tedious compared with tests so people don't go overboard with it. It is a much more safer route then testing, but much harder. Additionally as of now, the thing with python is that it really depends on how powerful the typechecker is on whether or not it can enforce and execute type level functions. It's certainly possible, it's just nobody has done it yet.

I'd go further than this actually. Python is actually a potentially more powerfully typed language than TS. In TS, types are basically another language tacked onto javascript. Both languages are totally different and the typing language is very very limited.

The thing with python is that the types and the language ARE the SAME thing. They live in the same universe. You complained about this, but there's a lot of power in that because basically types become turing complete and you can create a type that does anything including proving your whole program correct.

Like I said that power depends on the typechecker. Someone needs to create a typechecker that can recognize type level functions and so far it hasn't happened yet. But if you want to play with a language that does this, I believe that language is Idris.

Isn’t this solved in 3.14/PEP-649?

from __future__ import annotations

Except that typescript structural typing and features make it much easier to swim.

Also python is far less aggressive with lint warnings so it is much easier to make mistakes

> It was an illusion. We didn't like it more because of the lack of typing. These languages were embraced because they weren't C or C++.

It's an illusion only you once had. Java (a language that is not C or C++) got mainstream way before Python.