correct identification of stdlib TypeVar objs (#412)

* correct identification of stdlib TypeVar objs

In Python <= 3.7, the module attribute of TypeVar constructs is always
set to typing and thus irrelevant to the true origin of the construct
(stdlib, third-party, user-defined). cloudpickle used to cirumvent this
issue in `_whichmodule` by exhaustively search for the construct in all
imported modules. This would generate false positive in the case of
stdlib TypeVar constructs such as AnyStr being used by imported
third-party module. For such TypeVar construct, `_whichmodule` would
occasionally flag them as belonging to the third party module. This
resulted in a flaky test
(`test_lookup_module_and_qualname_stdlib_typevar`) where `typing.AnyStr`
was occasionally marked as defined in `_pytest.capture` instead of
`typing`.


Co-authored-by: Olivier Grisel <[email protected]>

Author: pierreglaser

Diff for: cloudpickle/cloudpickle.py

@@ -136,11 +136,14 @@ def _whichmodule(obj, name):
         # Workaround bug in old Python versions: prior to Python 3.7,
         # T.__module__ would always be set to "typing" even when the TypeVar T
         # would be defined in a different module.
-        #
-        # For such older Python versions, we ignore the __module__ attribute of
-        # TypeVar instances and instead exhaustively lookup those instances in
-        # all currently imported modules.
-        module_name = None
+        if name is not None and getattr(typing, name, None) is obj:
+            # Built-in TypeVar defined in typing such as AnyStr
+            return 'typing'
+        else:
+            # User defined or third-party TypeVar: __module__ attribute is
+            # irrelevant, thus trigger a exhaustive search for obj in all
+            # modules.
+            module_name = None
     else:
         module_name = getattr(obj, '__module__', None)