Closed Goldziher closed 3 months ago
Wouldn’t this overwrite the signature of the chunker returned by chunkerify()
in vscode? That’s what I’ve found. If I create a chunker with chunkerify()
and then hover over that chunker, unless the output of chunkerify()
is not type hinted, I will not be able to see its signature and docstring.
Wouldn’t this overwrite the signature of the chunker returned by
chunkerify()
in vscode? That’s what I’ve found. If I create a chunker withchunkerify()
and then hover over that chunker, unless the output ofchunkerify()
is not type hinted, I will not be able to see its signature and docstring.
It shouldn't, you had a typing issue. But more importantly - typing is more important than the editor completion you got, since it affects code used by the caller.
I'll try finding a solution that neither breaks typing nor code editor hints. Returning a custom object could be on the table with a __call__
method that ensures backwards compatibility with the current API.
I'll try finding a solution that neither breaks typing nor code editor hints. Returning a custom object could be on the table with a
__call__
method that ensures backwards compatibility with the current API.
I would suggest using a class that implements call in any case - since the code currently creates a huge function and uses its scope. it would be much cleaner to use a class with some private methods, and you could also consider than having both sync and async methods on the same class, or having subclasses of a base class.
I have fixed this in v2.2.0. I am still yet to get to #6.
This PR fixes the typing issue of the return of
cunkerify
.