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

Do not allow TypeVarTuple after TypeVar with a default #3265

Open
sobolevn opened this issue Jan 9, 2025 · 6 comments · May be fixed by #3314
Open

Do not allow TypeVarTuple after TypeVar with a default #3265

sobolevn opened this issue Jan 9, 2025 · 6 comments · May be fixed by #3314
Labels
good first issue Entrypoint to the project help wanted Extra attention is needed rule request Adding a new rule

Comments

@sobolevn
Copy link
Member

sobolevn commented Jan 9, 2025

There's a pattern that is allowed from typing perspective:

class X[T=int, *Ts=*tuple[int, ...]]: ...

https://mypy-play.net/?mypy=latest&python=3.13&gist=cbd582efc127e91a38a022d99ea7269f

But, it is a really bad pattern, because you cannot specify *Ts without specifing T

So, we need to find type_params definitions where TypeVar with default is followed by TypeVarTuple with default.

@sobolevn sobolevn added help wanted Extra attention is needed rule request Adding a new rule good first issue Entrypoint to the project labels Jan 9, 2025
@Tapeline
Copy link
Contributor

Tapeline commented Feb 6, 2025

Hi. I want to address this issue.

Did some research on it. I think the solution is as follows:

  1. Identify the typevars with defaults
  2. On each class declaration check for a pattern

However, there are some questions:

  1. Should we look only for TypeVar and TypeVarTuple identifiers or should we also consider possible import as?
  2. Should we consider scopes, or pretend that every typevar is globally declared?

@sobolevn
Copy link
Member Author

sobolevn commented Feb 6, 2025

We should only check for pep695 definitions. No imports. No global variables.

@Tapeline
Copy link
Contributor

Tapeline commented Feb 6, 2025

Given an example:

from typing import TypeVar

class MyClass[T]:
    V = TypeVar("V", default=int)
    
    def method(self, v: V) -> V:
        ...

    # V is accessible here

# but not here

Should we forget about V's existence after the class declaration, or pretend it's defined at the top level?

The first approach is more correct, but the second one is easier to implement

@sobolevn
Copy link
Member Author

sobolevn commented Feb 6, 2025

We only care about pep695 types here, no other cases :)

@Tapeline
Copy link
Contributor

Tapeline commented Feb 9, 2025

Where the rule should go? Into OOP or into Best practices section?

@sobolevn
Copy link
Member Author

sobolevn commented Feb 9, 2025

Best practices, near https://github.com/wemake-services/wemake-python-styleguide/blob/master/wemake_python_styleguide/violations/best_practices.py#L2969

Tapeline added a commit to Tapeline/wemake-python-styleguide that referenced this issue Feb 20, 2025
…thDefaultViolation and corresponding tests
@Tapeline Tapeline linked a pull request Feb 20, 2025 that will close this issue
4 tasks
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
good first issue Entrypoint to the project help wanted Extra attention is needed rule request Adding a new rule
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants