wemake-python-styleguide icon indicating copy to clipboard operation
wemake-python-styleguide copied to clipboard

Improve .pyi files support

Open sobolevn opened this issue 4 years ago • 5 comments

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

sobolevn avatar Mar 19 '20 07:03 sobolevn

Can be also tested on:

  • https://github.com/typeddjango/django-stubs
  • https://github.com/typeddjango/djangorestframework-stubs

sobolevn avatar Mar 19 '20 07:03 sobolevn

We should also allow almost any names in .pyi files. We cannot control it either.

sobolevn avatar Mar 19 '20 13:03 sobolevn

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.

sobolevn avatar Mar 19 '20 14:03 sobolevn

This is way too big for 0.14.

sobolevn avatar Mar 19 '20 14:03 sobolevn

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.

maltevesper avatar Mar 21 '21 22:03 maltevesper