Remove runtime conditions for type checking
Author: cyyever
Pull request: yes

# What does this PR do?
Linters aren't smart enough to evaluate the conditions.

Fixes #37339

Comments:
Hi 👋, thank you for opening this pull request! The pull request is converted to draft by default. The CI will be paused while the PR is in draft mode. When it is ready for review, please click the `Ready for review` button (at the bottom of the PR page). This will assign reviewers and trigger CI.

@cyyever I confirm, locally installing this branch fixes the issue https://github.com/huggingface/transformers/issues/37339 👍 

@cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

> @cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

There are wrapped in type_checking and used by linter, so that only linters would complain if there are missing symbols.

@ArthurZucker what's the status here? I get the errors after the PR you mentioned landed as well.

@ArthurZucker The CI failures are unrelated.

sorry everyone I am not sure I understand what is the issue here / setup to reproduce? 


Happy to merge if this is compatible with the recent init refactoring!

The rebase is quite recent

@ArthurZucker just rebased it.

@ydshieh  have a look?

@cyyever Got to say I am less familiar on this aspect 😅  . I see you answered

> There are wrapped in type_checking and used by linter, so that only linters would complain if there are missing symbols.

to @Rocketknight1 question

> @cyyever if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?

But I don't understand well:
- In #37339, do they have all the dependencies but yet still get the dummy objects (due to linter isn't smart enough?)
- `Linters aren't smart enough to evaluate the conditions.`: Is this mypy specific or any type checkers?
- I don't think we want to have exceptions when `linters would complain if there are missing symbols.`. I see you mentioned `__all__`. But in the meantime, do we have a way to avoid this? In other words, there is no way for linters to evaluate the conditions correctly ..?

Overall, I am open to merge, but we should resolve the case @Rocketknight1 mentioned at some point in the near future.


` if we remove the dynamic conditions for type checking, will this cause exceptions when those dependencies aren't present?`
No, because the import are wrapped inside TYPE_CHECKING, according to the doc:
```
 typing.TYPE_CHECKING

    A special constant that is assumed to be True by 3rd party static type checkers. It is False at runtime.
```
```
In
https://github.com/huggingface/transformers/issues/37339, do they have all the dependencies but yet still get the dummy objects (due to linter isn't smart enough?)
Linters aren't smart enough to evaluate the conditions.: Is this mypy specific or any type checkers?
```
Linters have to evaluate `XXX_is_available` in the old code and then catch an exception to deal with dummy objects or import the normal symbols, but I don't think most linters would be coded do that. At least mypy would fail, but I haven't check others.
```
I don't think we want to have exceptions when linters would complain if there are missing symbols.. I see you mentioned __all__. But in the meantime, do we have a way to avoid this? In other words, there is no way for linters to evaluate the conditions correctly ..?
```
It depends on what linters are allowed to do, and I don't consider dynamic evaluation is generally supported.


Wow thanks a lot for your PR @cyyever!

This seems to overlap slightly with this PR: https://github.com/huggingface/transformers/pull/37653

I agree with your statement that most of these type checkings are unnecessary because type checkers don't work this way.
I'm planning on merging #37653 before the next release; @cyyever do you mind if I add you as co-author as we worked on the same topic?

@LysandreJik Thank you, we can work together.

Is it possible to merge it? Because I have to recheck the changes in case __init__.py has more changes.

Could we have some progress on this work because users are complaining about mypy...

cc @arthurzucker @cyrilvallez the init refactor is done, I think this is ready for final review/approval!

Can you check if the failing test is related or not?

The docs for this PR live [here](https://moon-ci-docs.huggingface.co/docs/transformers/pr_37340). All of your documentation changes will be reflected on that endpoint. The docs are available until 30 days after the last update.

@ArthurZucker It is a test numerical error, not an import error, so it is unrelated.

@ArthurZucker No failure 

Merging!

Thanks 🤗