IDE cannot correctly navigate to references, It will navigate all object to `transformers/utils/dummy_pt_objects.py`.
Author: liyucheng09
Pull request: no

# Enviornment

- `transformers` version: 4.5.1
- Platform: macOS-11.1-arm64-arm-64bit
- Python version: 3.9.1
- PyTorch version (GPU?): 1.8.0 (False)
- Tensorflow version (GPU?): not installed (NA)
- Using GPU in script?: <fill in>
- Using distributed or parallel set-up in script?: <fill in>

# Issues

When using PyCharm or VSCode with `Pylance` (an extension), right-click model object will navigate users to `transformers/utils/dummy_pt_objects.py` rather than the correct path.

Comments:
In PyCharm, you can select all `dummy*` files, right-click and select "Mark as Plain Text". This should prevent the IDE from navigating to the dummy files.
I have never used VSCode with `Pylance` however.

need some help from vscode user, does anyone found the same issue?

I'm also having this issue with VS Code.

Hello @liyucheng09!

This happens due to dynamic checks that happen to optimize imports in the transformers codebase. (e.g. when you import fast tokenizers using `is_tokenizers_available()` method ([example](https://github.com/huggingface/transformers/blob/3694484d0ae6f1b2e4f60460d6767f5d90442ba9/src/transformers/__init__.py#L1912)) Pylance isn't able to infer such value while analysing and thus uses the else branch statements instead which leads to using dummy classes as if you haven't got tokenizers available).

Unfortunately, there is not much you can do. Pylance team recommends reaching out to maintainers in order to make code compatible with Pyright/Pylance static analyzer. 

Also, you can patch the installed module to make it compatible with Pylance:
https://gist.github.com/mozharovsky/0753e9eba28cda8890e2daa009c5e0b3

This issue has been automatically marked as stale because it has not had recent activity. If you think this still needs to be addressed please comment on this thread.

Please note that issues that do not follow the [contributing guidelines](https://github.com/huggingface/transformers/blob/master/CONTRIBUTING.md) are likely to be ignored.

Can this be reopened? It is still occurring and bothersome. The solution proposed by @mozharovsky is a good one, it can be converted into a PR if one of the maintainers agree.

The solution proposed by @mozharovsky would not reflect the reality when you don't have a dependency installed (for instance if you don't have tokenziers installed, it's normal to be sent to the dummy object by your IDE). It would also need to rewrite part of our internal tooling that checks the consistency of the inits. Not saying it's impossible but it's quite a bit of work.

None of the main maintainers will work on this, but we can look at a PR if someone is motivated enough. We won't give up the dynamic checks that happen to optimize the imports however.



Ok, fair enough. I can probably work on it. What is this internal tooling you're talking about? Could you give a link to the part that needs changing? This issue is important because it makes code completion and type checking unusable for users of vscode and mypy.

The internal tooling checking the inits is [here](https://github.com/huggingface/transformers/blob/master/utils/check_inits.py). I'm not sure how it will behave after a change in the inits, so I can't point to you the exact part that will need changing once the inits are modified :-)

Thanks for the link, I'll take a look! Regarding not reflecting the reality, it's true what you said. But it's impossible to determine if another library is installed during static type checking. Given this, what is the preferred option - 

A. All users get code completion and avoid type checking errors, even if some dependencies are missing

B. None of the users will have code completion and everyone gets type errors even if they have dependencies installed

I think A. If you disagree please tell me now so I can avoid working on the PR :)

Pyright and Pylance recently added this change: https://github.com/microsoft/pylance-release/issues/2402

I think this should now be straightforward to resolve by replacing the conditional statements highlighted by @mozharovsky with `try/except`.