Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

WPS356 (unnecessary iterable unpacking) incompatible with Variadic Generics #2699

Open
aaronmondal opened this issue Jul 28, 2023 · 3 comments
Labels
bug Something isn't working

Comments

@aaronmondal
Copy link

aaronmondal commented Jul 28, 2023

What's wrong

The following is not allowed by WPS356:

from typing import Generic, Self, Tuple, TypeVar, TypeVarTuple


DType = TypeVar('DType')
Shape = TypeVarTuple('Shape')


class Array(Generic[DType, *Shape]):
    ...
    
    def resize_to_shape(
        self: Self,
        shape: Tuple[*Shape],  # Error.
    ) -> Self

How it should be

According to https://peps.python.org/pep-0646/#type-variable-tuples-must-always-be-unpacked it is a hard requirement to unpack Shape in this case. Since wemake doesn't cover typing, it should ignore this case entirely.

Flake8 version and plugins

Python 3.11
Flake8 6.0.0 with all plugins from wemake-python-styleguide 0.18.0

pip information

pip 23.2.1 (python 3.11)

OS information

Gentoo

@aaronmondal aaronmondal added the bug Something isn't working label Jul 28, 2023
@aaronmondal aaronmondal changed the title WPS356 (unnecessary iterable unpacking) incompatible with Generics WPS356 (unnecessary iterable unpacking) incompatible with Variadic Generics Jul 28, 2023
@sobolevn
Copy link
Member

Yes, we should ignore this case.

  1. We can ignore all cases in annotations
  2. What to do with type aliases on module and class levels?

@aaronmondal
Copy link
Author

  1. What to do with type aliases on module and class levels?

This seems like a tricky issue in general. Just from playing around with things for a short tim I've encountered quite a few cases that confuse wemake. For instance, this is flagged (which would be fixed by 1):

from typing import Literal

Height: Literal[128] = 128  # Triggers WPS432 avoid magic number

But I assume the following doesn't count as "annotation":

from typing import Literal

SymbolicOne = Literal[1]  # Also triggers WPS432.

I'm just guessing here, maybe letting wemake know about Generic Aliases could be helpful? Giving wemake deeper knowledge about types just so that it can ignore them seems like a lot of effort though 😅

Maybe a config flag for code that disables a certain set of warnings for generic code could be an option? Certainly not an optimal solution, but seems a lot easier to implement than knowledge about types.

@sobolevn
Copy link
Member

One way to allow *TVT is to allow it in SomeType[*TVT], but not in [*TVT]
I will comment on Literal later, I am focusing on one task per commit right now :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants