mypy typechecking and circular dependency issues about crosshair HOT 4 CLOSED

First, thank you for the very detailed repro instructions!

This is a tricky problem and solving it would unlock a lot of use cases for CrossHair. Unfortunately, it is also one that I'm going to need to think about. First, I'll start with some internals:

Unlike mypy, CrossHair works by actually importing and running your code. It just passes very special fake values to your functions to do its magic. It needs to understand both the function under test, as well as the types on the supplied parameters. In your example, for instance, if we remove the TYPE_CHECKING guard, simply running python foobar/bar.py (without CrossHair) will produce the same error.

That said, perhaps we can do some trickery. I'm imagining something like: import with TYPE_CHECKING off and then re-import with it on. I'll experiment with this over the next few days and report back with what I discover.

from crosshair.

I understand. I do consider circular dependencies as unwanted design, to be avoided as much as possible. Unfortunately I'm working with a code base that does have 'm, in large amounts, and no time to remove/replace them.
What I can do and might help find a way around it, is the way I do these imports:

I'm also not very fond of using the TYPE_CHECKING flag; very framework specific, limits my control over the code. So I'd rather do without it. Maybe the trickery can cover something like replacing the import statement with a function that does conditional imports:

from no.circular.dependency.module.a_class import A_class
 
cond_import({"module_name":"class(es)"})

class ThisClass:
    ...

Then in the cond_import function, I have a single TYPE_CHECKING flag and all I need to do the importing and maybe break/prevent circular importing and what not?

But maybe this b0rks MyPy...

from crosshair.

Yeah, I suspect that hiding the TYPE_CHECKING guard will confuse type checkers.

However, I just attempted an odd sort of fix where CrossHair will detect the presence of these guards and attempt a re-import with them turned on. Not all modules are guaranteed to re-import properly, but this behavior still seems like a good compromise to me.

@CoenSchalkwijk Would you try again at HEAD and let me know how it goes? Thanks for your help here!

from crosshair.

Discovered in #172, I am newly of the opinion that it's a mistake to even attempt an import with TYPE_CHECKING=True.
pytorch, for instance, uses the guard to import via .pyi files, which are obviously not importable at runtime.

Sadly, this means that crosshair will be able to understand fewer type annotations. (including the one in the original example) Its behavior will correspond directly to the type annotations that are present at runtime, however: so that behavior is at least easy to explain. A different way to say this is that CrossHair's ability to understand type annotations will be roughly similar to any other tool that analyzes type annotations at runtime.

I am nevertheless saddened that we won't be able to handle this kind of situation. I have some optimism that Python is (slowly) evolving in directions that enhances typing use cases at runtime, so perhaps this wart becomes less apparent over time.

from crosshair.