encode / httpx

A next generation HTTP client for Python. 🦋

Home Page:https://www.python-httpx.org/

Geek Repo:Geek Repo

Github PK Tool:Github PK Tool

Requests for new public APIs

karpetrosyan opened this issue · comments

Ref: encode/starlette#2534 (comment)

This issue was opened to resolve all kinds of problems where third-party packages may need to use private imports. We should definitely expose them to avoid problems like #3130 (comment).

I will include the package name along with its private imports (only starlette for now), so we can clearly identify what needs to be exposed.

Note that:

  • -> Not yet publicly exposed
  • -> Publicly exposed

We can also add other packages as well to track all of them in this issue.

Starlette

Thanks @karpetrosyan ☺️

We should definitely expose them

So... I'm not necessarily(?) convinced that's the outcome I'd like to see here.
Mostly I think these types end up obscuring the actual API and are code smells that should be squished.

For example, switching to the following* seems clearer to me...

   url : httpx.URL | str,
   headers: httpx.Header | Mapping[str, str] | Sequence[Tuple[str, str]],
   params: httpx.QueryParams | Mapping[str, str] | Sequence[Tuple[str, str]],
   ...

* useful starting point for discussion

I'm curios why not just expose _types module instead?

from httpx.types import HeaderTypes, QueryParamsTypes, URLTypes

...

   url : URLTypes | str,
   headers: HeaderTypes | Mapping[str, str] | Sequence[Tuple[str, str]],
   params: QueryParamsTypes | Mapping[str, str] | Sequence[Tuple[str, str]],
   ...

I'm curios why not just expose _types module instead?

Mostly I think these types end up obscuring the actual API and are code smells that should be squished.