How to resolve importing a function from a module with same name about pyre-check HOT 6 OPEN

Hi @henrylhtsang.

Unfortunately, there's an architectural issue in Pyre (and a number of other tools too) where we assume that a fully qualified name means something unambiguous in Python, so that torchrec.distributed.shard has to refer to either a module or a function but not both.

The pattern of shadowing a module with a function imported into the parent then causes any tool indexing the code this way to fail to understand it. Until recently, Pyre was failing to analyze the code (which meant it dropped type information) silently, and we recently changed Pyre to warn users that the import can't be analyzed.

This is pretty disruptive, and we also hope we can change Pyre to understand that fully qualified names are not unambiguous and it's necessary to model the effect of an import on scope more precisely, but this will take at least several months for us to fix, possibly longer.

In the meantime, your best bet is probably to rename something. Because you are a library and backward compatibility matters, it's tricky to decide what exactly to do, but:

• if users typically run from torchrec.distributed import shard then you probably don't want to change the meaning of that, which means you might want to change shard.py to sharding.py or something like that
• if you're worried that users are also directly importing the module (import torchrec.distributed.shard, or from torchrec.distributed.shard import <something>, then you could potentially also keep shard.py and modify it to just from .sharding import *. At that point, Pyre won't be able to see shard.py but at least at runtime it will be there, so users won't see breakages (unless they are using Pyre)

from pyre-check.

Totally understand the frustration. This is a known issue. Unfortunately, the fix will take some time to land, so I would recommend finding a workaround.

from pyre-check.

@migeed-z thanks, is there a timeline?

from pyre-check.

(You can of course use a # pyre-ignore to suppress the error you are seeing, but unfortunately users of your library who are using Pyre - which includes most Meta users - will run into the same problem in that case so I wouldn't recommend that approach)

from pyre-check.

@stroxler thanks, will explore changing names

from pyre-check.

This is a duplicate of #232

from pyre-check.