The __eq__ method of ForwardRef does not take into account the module parameter. 

However, ForwardRefs with dissimilar module parameters are referring to different types even if they have different name. Thus also the ForwardRef's with same name but different module, should not be considered equal.


Consider the following code


from typing import *

ZZ = Optional['YY'] 
YY = int

YY = Tuple[Optional[ForwardRef("YY", module=__name__)], int]
print( YY.__args__[0].__args__[0].__forward_module__ )
# this prints None, but should print __main__ (or whatever __name__ contains)


When the first ForwardRef is not created, the program behaves correctly

#ZZ = Optional['YY'] 
YY = int

YY = Tuple[Optional[ForwardRef("YY", module=__name__)], int]
print( YY.__args__[0].__args__[0].__forward_module__ )
# this prints __main__ (or whatever __name__ contains)



The issue is that the line `ZZ = Optional['YY']` creates a cache entry, which is re-used instead of the second definition `Optional[ForwardRef("YY", module=__name__)]` and thus shadows the different argument of ForwardRef.


This problem could be fixed if the __eq__ method of FowardRef also checks for module equality.

i.e. in ForwardRef.__eq__ in typing.py replace 

   return self.__forward_arg__ == other.__forward_arg__

with 

   return self.__forward_arg__ == other.__forward_arg__  and  self.__forward__module__ == other.__forward__module__ 


Ideally, (and for consistency reasons) the `__repr__` method of `ForwardRef` would also include the module arg if it present:

Change:

    def __repr__(self):
        return f'ForwardRef({self.__forward_arg__!r})'

to 

    def __repr__(self):
        if self.__forward_module__ is None:
            return f'ForwardRef({self.__forward_arg__!r})'
        else:
            return f'ForwardRef({self.__forward_arg__!r}, module={self.__forward__module!r})'

Good catch. Do you want to submit a PR? I agree that the repr() could also be better (but please only show other values if they differ from the default).

I will give it a try.

@Andreas
First of all, thanks for addressing my questions on the PR. I have one more question which I'll post here since it's not entirely related to your PR.

ForwardRef isn't meant to be explicitly instantiated by a user [1] (it's a typing internal class), so do you mind sharing what your current use case is please? My concern here is that exposing things in __repr__ would force us to keep `module` forever (I'm 100% fine with __eq__ and __hash__). After digging up the commit history, I now recall that the module parameter was used solely as a fix for ForwardRefs in different-module TypedDict (see GH-27017 or bpo-41249). It's not used anywhere else, so I don't know if your current use case was ever intended when the module parameter was added.

[1]: https://docs.python.org/3/library/typing.html#typing.ForwardRef

Yeah, sure. The use-case is (de)serialization. Right now I use the library cattr, but there are many others. 

If you are interested there is related discussion in the cattr board [1].


The original problem is how to define the types for serialization.

1. If everything is a class, things work well, but not if type aliases are used: 

2. Type aliases sometimes have to be used - they cannot be avoided in all cases, 
   especially with recursive types. The famous example is 

      Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]

   (Note: even though mypy does not support this construct, pylance meanwhile does [2])

3. `typing.Annotated` seems to be made for specifying additional information such as value ranges, right to be used
   in (de)serialization + validation contexts. Often these will just be type aliases (not used as class members). 
   Combination is possible with typing.NewType.


The problem is that the implicit `ForwardRef('Json')` cannot be automatically resolved (as it only a name with no context). 
There is really no way this could be handle inside a library such as cattr.  

When one wants to separate interface from implementation this issue is even more complicated. The module where the serialization function is called is typically different from the module with the type definition (This is probably more the norm than the exception)



The option I expored is to explicitly create the ForwardRef and specify the module parameter (even though I have to admit that I also did read that the ForwardRef is only for internal use). 
   
    Json = Union[ List[ForwardRef(Json',module=__name__)], Dict[str, ForwardRef(Json',module=__name__)], int, float, bool, None ]

Ugly, but this is better than nothing.


A (worse) alternative is to do

    Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]
    typing._eval_type(Json, globals(), locals())

That works since it puts the ForwardRefs into "evaluated" state (self.__forward_value__ is then set)



A third, but future, alternative could be to automatically decompose the argument of ForwardRef into module and type. Then one could write

   Json = Union[ List[__name__+'.Json'], Dict[str, __name__+'.Json'], int, float, bool, None ]

and all above problems would be solved.

Then ForwardRef could stay internal and this is more readable. Even though, the static type checkers would need to understand `__name__+'TYPE'` constructs to be useful.


Anyhow, it would be nice to have a solution here.



[1]: https://github.com/python-attrs/cattrs/issues/201
[2]: https://devblogs.microsoft.com/python/pylance-introduces-five-new-features-that-enable-type-magic-for-python-developers/

Ah, let me add one point: PEP563  (-> `from __future__ import annotations`) is also not helping. 

Even with PEP563 enabled, the JSON example  

   Json = Union[ List['Json'], Dict[str, 'Json'], int, float, bool, None ]

needs to be written in exact the same way as without PEP563. In other words there are cases where `ForwardRef` cannot be avoided. And unforntunately these are the cases where we have the ForwardRef missing context issue.