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

extraneous reportArgumentType when calling super().__init__ #9901

Open
Alan-Chen99 opened this issue Feb 12, 2025 · 5 comments
Open

extraneous reportArgumentType when calling super().__init__ #9901

Alan-Chen99 opened this issue Feb 12, 2025 · 5 comments
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working

Comments

@Alan-Chen99
Copy link

class Parameter:
    def __init__(self, name):
        pass


class testclass:
    def __init__(
        self, x: list[Parameter] = None
    ):  # error: Expression of type "None" cannot be assigned to parameter of type "list[Parameter]
        pass


class testclass2(testclass):
    def __init__(self):
        # I expect no error here
        super().__init__()  # error: Argument of type "None" cannot be assigned to parameter "x" of type "list[Parameter]" in function "__init__"

This is annoying when testclass is from a dependency.

$ pyright --version
pyright 1.1.394
@Alan-Chen99 Alan-Chen99 added the bug Something isn't working label Feb 12, 2025
@erictraut
Copy link
Collaborator

Pyright is working as intended here. The default value has type None which is not assignable to the type list[Parameter].

Your options are:

  1. Fix the bug in the testclass.__init__ method. (While this is the recommended option, it sounds like this may not be possible if it's coming from a dependency that you don't have control over.)
  2. In your pyright config file for this project, set strictParameterNoneValue to false. This tells pyright to use the (now obsolete) convention that a None default argument value should imply an Optional parameter type.
  3. Suppress the error in testclass2.__init__ using a # type: ignore or # pragma: ignore.

@erictraut erictraut closed this as not planned Won't fix, can't repro, duplicate, stale Feb 12, 2025
@erictraut erictraut added the as designed Not a bug, working as intended label Feb 12, 2025
@Alan-Chen99
Copy link
Author

It is inconsistent though; it no longer errors if you do

class Parameter:
    def __init__(self):
        pass

instead.

@erictraut
Copy link
Collaborator

Yeah, that's inconsistent. I'll reopen and investigate further.

@erictraut erictraut reopened this Feb 12, 2025
@erictraut erictraut removed the as designed Not a bug, working as intended label Feb 12, 2025
erictraut added a commit that referenced this issue Feb 15, 2025
…ing the evaluation of a call whose target signature involves a parameter with a default argument value, notably where the type of the default value isn't assignable to the declared type of its parameter. This addresses #9901.
erictraut added a commit that referenced this issue Feb 15, 2025
…ing the evaluation of a call whose target signature involves a parameter with a default argument value, notably where the type of the default value isn't assignable to the declared type of its parameter. This addresses #9901. (#9922)
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Feb 15, 2025
@erictraut
Copy link
Collaborator

This is addressed in pyright 1.1.395.

@erictraut
Copy link
Collaborator

The fix for this inconsistency resulted in a regression that is affecting many pyright users. I'm going to back out this change and reopen the issue so I have time to reconsider the approach.

erictraut added a commit that referenced this issue Feb 28, 2025
…s involving the evaluation of a call whose target signature involves a parameter with a default argument value, notably where the type of the default value isn't assignable to the declared type of its parameter. This addresses #9901. (#9922)"

This reverts commit f873dbf.
erictraut added a commit that referenced this issue Feb 28, 2025
…s involving the evaluation of a call whose target signature involves a parameter with a default argument value, notably where the type of the default value isn't assignable to the declared type of its parameter. This addresses #9901. (#9922)"

This reverts commit f873dbf.
erictraut added a commit that referenced this issue Mar 4, 2025
…tion with a default argument that is not assignable to the declared parameter type. An error will still be reported in the case where the declared parameter type includes an unsolved type variable in most cases, but it will no longer be reported if the unsolved type variable is due to a pseudo-generic class. This addresses #9901.
erictraut added a commit that referenced this issue Mar 4, 2025
…tion with a default argument that is not assignable to the declared parameter type. An error will still be reported in the case where the declared parameter type includes an unsolved type variable in most cases, but it will no longer be reported if the unsolved type variable is due to a pseudo-generic class. This addresses #9901. (#10028)
@erictraut erictraut added the addressed in next version Issue is fixed and will appear in next published version label Mar 4, 2025
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
addressed in next version Issue is fixed and will appear in next published version bug Something isn't working
Projects
None yet
Development

No branches or pull requests

2 participants