narrow client request methods down

[cansarigol]

#174
Hi, I tried to narrow Client methods down with TypeDict. However, does not seem possible until the issue fixed. This code may be useful.

[florimondmanca]

Interesting take, thanks! It’s great to see a possible solution to better typing support of **kwargs.

How well does this work with autocompletion, though? I suppose this was the main motivation for repeating the keyword arguments in the client methods.

I think there’s a big blocker, though — TypeDict is a new, 3.8-only feature of the typing module, but we support 3.6 and up. So I don’t think this will make it but I really appreciate you giving this a shot.

(Though, I’m not sure the approach demonstrated here was the idea behind #174. We definitely need to discuss the proposed scope and API of build_request() there.)

[cansarigol]

Thanks for review.

How well does this work with autocompletion, though? I suppose this was the main motivation for repeating the keyword arguments in the client methods.

I've been trying to fix two things. First, use one line client functions and decorate them with a generic function to handle their signature. Second, when mypy runs, it introspects generic arguments from kwargs.

I don't know how IDEs handle moving autocomplete arguments. added a decorator to override client function's signature. With bind or bind_partial functions, I can check their arguments in runtime but in design time it doesn't work. I use vscode but I'm not sure about Pycharm.

I think there’s a big blocker, though — TypeDict is a new, 3.8-only feature of the typing module, but we support 3.6 and up. So I don’t think this will make it but I really appreciate you giving this a shot.

Are you sure about this? because it comes from mypy_extensions module and I didn't get any error.

[florimondmanca]

Are you sure about this? because it comes from mypy_extensions module and I didn't get any error.

Oh, indeed. Cool!

First, use one line client functions and decorate them with a generic function to handle their signature.

From experience, signature-altering decorators don't play that well with IDEs (because those generally rely on the initial signature of the function). I'll give it a go in VSCode when I have some time, and we'll see. :)

[cansarigol]

by the way, I came across this issue I'm watching it.

[florimondmanca]

VSCode isn't giving me any autocompletions, and IPython can't see the signature either:

Compare with httpx.get:

[florimondmanca]

Overall, I'm not sure this is something we even want to have. Sure, repeating the arguments looks cumbersome but it's not that much of a maintenance burden, it makes very explicit what these methods accept, and it gives a nice editor experience.

(Edit: there's also the question of what we would do with the AsyncClient's methods? Really, I think we're fine with things are they are today.)

Would love to have @sethmlarson's point of view on this. :-)

[cansarigol]

at least I added share_signature 😄

>>> import httpx
>>> httpx.Client.get.__signature__
<Signature (self, method: str, url: Union[ForwardRef('URL'), str], *, data: Union[dict, str, bytes, Iterator[bytes]] = None, files: Dict[str, Union[IO[
~AnyStr], Tuple[str, IO[~AnyStr]], Tuple[str, IO[~AnyStr], str]]] = None, json: Any = None, params: Union[ForwardRef('QueryParams'), Mapping[str, Union
[str, int, float, bool, NoneType]], List[Tuple[str, Union[str, int, float, bool, NoneType]]], str] = None, headers: Union[ForwardRef('Headers'), Dict[~
AnyStr, ~AnyStr], List[Tuple[~AnyStr, ~AnyStr]]] = None, cookies: Union[ForwardRef('Cookies'), http.cookiejar.CookieJar, Dict[str, str]] = None, stream
: bool = False, auth: Union[Tuple[Union[str, bytes], Union[str, bytes]], Callable[[ForwardRef('AsyncRequest')], ForwardRef('AsyncRequest')]] = None, al
low_redirects: bool = True, cert: Union[str, Tuple[str, str], Tuple[str, str, str]] = None, verify: Union[str, bool, ssl.SSLContext] = None, timeout: U
nion[float, Tuple[float, float, float], ForwardRef('TimeoutConfig')] = None, trust_env: bool = None) -> httpx.models.Response>
>>> 

[florimondmanca]

So, I’m going to close this because I think it’s not something we need, esp with respect to maintaining the readability, ease of maintenance and editor support of the client. But thanks again for trying it out! (In the future, feel free to open issues to discuss this kind of idea, if you’d like a quick feedback on whether it’s something worth working on.)