Allow IDEs to autocomplete method signatures

[DefiDebauchery]

When directly using methods decorated with @endpoint, IDEs won't read and recommend arguments:

    @endpoint('/v2/delegates')
    async def get_delegates(self, query_params: V2DelegatesFilter) -> SafeDelegateResponse:
        ...

This makes it difficult to remember what params are used. (I don't mind instantiating the Pydantic Filter since it autocompletes, but the IDE won't even tell me that this method requires V2DelegatesFilter)

The workarounds to this all require duplication:

1. Rename decorated method to be internal and add a public one with the
2. Duplicate the Filter as a TypedDict and use typing.Union (which might work with meatie if it handles TypedDicts, but foregoes the Pydantic-specific methods my BaseFilter has, including the custom unwrap())
3. Define stubs in a .pyi file.

My (very rudimentary) understanding is that the decorator needs to do something with the function signature, but I was personally unable to work out how to make that happen.

Unsure if this is feasible to do, but any 'auto-magic' ways to interact with the endpoints in my IDE would be really helpful!

[pmateusz]

Hi @DefiDebauchery,

Thank you for pointing out this problem. For a long time, this area could not be much improved due to the flexibility of Python (which allows dynamic code generation) and the limitations of type checkers such as mypy. The issue you opened motivated me to explore this topic further, hoping to improve the overall developer experience of using the library.

I reviewed the type hint declarations and strengthened some of them in the PR: #194.

These changes are subtle. Some lack strong justification, especially the type overloads that are rejected by mypy but help IDEs recognize sync/async methods.

With these changes in place, autocompletion in my IDE (I am currently using Cursor) worked for both methods and type arguments for the code examples available in the library.

I am going to release these changes soon. Could you let me know if the overall type hinting support improved in the new version of the library?

[pmateusz]

Hi @DefiDebauchery,

I've finished carefully testing the new release on a large batch of clients and have already released two hotfixes to address the mypy issues that came up.

Overall, I am very happy with the improvement. I believe it's the most important feature released this year. Thanks to the type hint improvements the autocompletion works, and I managed to find a few dozen valid type issues in HTTP clients in a commerical project that extensively uses meatie.

[DefiDebauchery]

This is great! In 0.1.26, PyCharm properly gives me the argument list for decorated endpoints.

I will note that it doesn't currently identify typing mismatch on my side; it's happy to allow me to write client.get_delegates('asdf'). I'm unsure if this is a limitation of the dynamic code generation as you mentioned, or of PyCharm itself.

Obviously this isn't necessarily a showstopper, as simply knowing which arguments it should have is certainly a massive improvement, but wanted to at least mention it.

[pmateusz]

JetBrains utilizes an in-house solution for Python type checking, which appears to prioritize real-time feedback over the quality (or 'thoroughness') of the analysis.

In my own workflow, I use mypy combined with 'meatie.' Since updating to 'meatie' version 0.1.26, it is now designed to catch issues like argument type mismatches, attempts to use undeclared positional arguments, or the use of undeclared named arguments. In fact, I was fixing those exact type errors yesterday right after upgrading 'meatie' in my commercial project.

Could you try mypy? You may also send me a code sample for verification.