Open disrupted opened 1 year ago
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!!
thanks for the swift reply, that's great to hear!
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?
I'll have a look, thanks for the feedback
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.
I found this issue which sounds like what we want, but wasn't able to solve it. https://github.com/python/mypy/issues/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:
...
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).
perhaps we could open an issue there to ask for advice.
Pyright currently complains when using dtyper as a drop-in replacement that
@app.command
decorators are missingself
as parameter.probably it could be solved by adding more complete type annotations to dtyper.