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

Support for type checking with Pyright #8

Open
disrupted opened this issue Aug 1, 2023 · 7 comments
Open

Support for type checking with Pyright #8

disrupted opened this issue Aug 1, 2023 · 7 comments

Comments

@disrupted
Copy link
Contributor

Pyright currently complains when using dtyper as a drop-in replacement that @app.command decorators are missing self as parameter.

error: Type of "command" is partially unknown
    Type of "command" is "_Wrapped[(self: typer.main.Typer, name: str | None = None, *, cls: type[TyperCommand] | None = None, context_settings: Dict[Any, Any] | None = None, help: str | None = None, epilog: str | None = None, short_help: str | None = None, options_metavar: str = "[OPTIONS]", add_help_option: bool = True, no_args_is_help: bool = False, hidden: bool = False, deprecated: bool = False, rich_help_panel: str | None = Default(None)), (CommandFunctionType@command) -> CommandFunctionType@command, (self: dtyper.Typer, *a: Unknown, **ka: Unknown), _Wrapped[(CommandFunctionType@command), CommandFunctionType@command, (f: Unknown), (...) -> Unknown]]" (reportUnknownMemberType)
error: Argument missing for parameter "self" (reportGeneralTypeIssues)
error: Untyped function decorator obscures type of function; ignoring decorator (reportUntypedFunctionDecorator)

probably it could be solved by adding more complete type annotations to dtyper.

@rec
Copy link
Owner

rec commented Aug 1, 2023

Hello, and sorry for the delay! I'm doing a release of some other unrelated project as I write; but the good news is that I know a lot more about typing than I did when I wrote dtyper so adding it should be, well, easier anyway.

Make a comment, it will sit in my inbox, I'll get to it tomorrow.

Thanks for using my work!!

@disrupted
Copy link
Contributor Author

thanks for the swift reply, that's great to hear!

@rec
Copy link
Owner

rec commented Oct 4, 2023

Very, very sorry about the delay!

Two things happened. First, I wasn't able to solve the problem in several hours of work, and I intended to go back to it, but then the job became horrible, and my time vanished.

I'm still TBH not sure how to solve this issue, nor am I able to make dtyper.dataclass typesafe, which now bothers me all the time.

Got any ideas?

@disrupted
Copy link
Contributor Author

disrupted commented Oct 5, 2023

I'll have a look, thanks for the feedback

@rec
Copy link
Owner

rec commented Oct 5, 2023

I've got plenty of time right now, that last job collapsed, so I can be super responsive, and now it's personal :-D since it's getting in my way.

@disrupted
Copy link
Contributor Author

disrupted commented Oct 5, 2023

I found this issue which sounds like what we want, but wasn't able to solve it. python/mypy#7778

As a current workaround, it's possible to repeat app as the self-Parameter in the decorator

edit: nevermind, this errors at runtime

app = dtyper.Typer()

@app.command(app, help="test")
def test(
    ...
) -> None:
    ...

@disrupted
Copy link
Contributor Author

disrupted commented Oct 12, 2023

I believe @wraps is used correctly, but likely the typing stubs from typeshed aren't suitable to detect that self is already present since the decorator is defined as a method of Typer (we're already inside an instance of the class).

https://github.com/python/typeshed/blob/95cee3100aeae722005fa9cd26f36907e25fccb6/stdlib/functools.pyi#L121

perhaps we could open an issue there to ask for advice.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants