wemake-python-styleguide
wemake-python-styleguide copied to clipboard
Improve .pyi files support
Currently, we have a lot of rules that are not very aligned with .pyi
files.
Here are some of them:
-
...
usage as a placeholder - complexity rules like number of arguments, methods, etc (we cannot control things like it in annotations)
And probably others as well.
What we need to do here is ignoring this violations when filename
has .pyi
extension.
And better docs about this case.
Related: https://github.com/dry-python/returns/blob/master/setup.cfg#L50
Can be also tested on:
- https://github.com/typeddjango/django-stubs
- https://github.com/typeddjango/djangorestframework-stubs
We should also allow almost any names in .pyi
files. We cannot control it either.
Also ignoring:
- [ ] WPS605, because methods can have 0 arguments in stubs
- [ ] WPS604, because all magic methods can be used in stubs
- [ ] WPS602, because
@staticmethod
can be used in stubs - [ ] WPS600, because classes can subtype builtins in stubs
- [ ] WPS431, because there can be nested classes
- [ ] WPS428, because we use
...
in stubs - [ ] WPS412, because
__init__.py
can have logic - [ ] WPS410, because we should allow different metadata variables
- [ ] WPS113, because mypy requires
as
imports for pubic API
Complexity rules (I still need to look through all of them):
- [ ] WPS235, because we cannot control the number of imports
- [ ] WPS215, because we cannot control the number of base classes
We also need a --external-stubs
config flag to enable this mode.
Otherwise, we are still writing our own stubs. That have a limited set of silenced violations.
This is way too big for 0.14
.
WPS211 is another complexity rule to consider for ignoring, It should already trigger on the actual implementation in the .py file.
Would it make sense to ignore WPS211 (too many args) and WPS428 (Ellipsis as unused code) on @overload
stubs in .py files too?
The logic for WPS211 is that it is already caught in the actual implementation, warning in other places requires cluttering #noqa
comments through the file if one has a valid exception.