Increasing type coverage for five different providers#11170
Increasing type coverage for five different providers#11170XD-DENG merged 2 commits intoapache:masterfrom mlgruby:gruby-dev-typing-coverage
Conversation
|
0.000000 dingding |
There was a problem hiding this comment.
Too many Any are used where they should be more specific type (say str, case by case).
Doing this (adding Any as type annotation, where it should be a more specific type) causes impression that "we have higher type coverage", but it does not really contribute much real value (in my opinion). def func(x: Any) is no difference from def func(x).
I pointed three such issues below, but there are more.
|
@XD-DENG Yup, make sense. Added more strict type now! |
| def __eq__(self, other) -> bool: | ||
| def __eq__(self, other: object) -> bool: | ||
| if not isinstance(other, RunState): | ||
| return NotImplemented |
There was a problem hiding this comment.
It's a special value, which should be returned by binary special methods, we could have a raise for NotImplementedError.
More info here: https://docs.python.org/3/library/constants.html#NotImplemented
3 participants
Increasing type coverage for multiple providers. Part of: #9708
cc: @kaxil @mik-laj another type coverage one, can I request for review of this PR?
^ Add meaningful description above
Read the Pull Request Guidelines for more information.
In case of fundamental code change, Airflow Improvement Proposal (AIP) is needed.
In case of a new dependency, check compliance with the ASF 3rd Party License Policy.
In case of backwards incompatible changes please leave a note in UPDATING.md.