Allow params={'pretty':None} to send query arg withOUT an equal sign

[jamshid]

I guess this is a followup to #1261. Please reconsider this:

https://www.python-httpx.org/compatibility/

Query Parameters
requests omits params whose values are None (e.g. requests.get(..., params={"foo": None})). This is not supported by HTTPX.

IMO it would be good and fine to break requests compatibility here.
I doubt many put a no-op "foo":None entry into params when using requests and it's likely nobody has on httpx 0.x.

Query args without an equal sign are in wide usage. E.g. elasticsearch's apis with ?pretty to format the json response or AWS' apis:
https://docs.aws.amazon.com/AmazonS3/latest/userguide/RESTAuthentication.html#ConstructingTheCanonicalizedResourceElement

If the request addresses a subresource, such as ?versioning, ?location, ?acl, ?torrent, ?lifecycle, or ?versionid, append the subresource, its value if it has one, and the question mark.

It's true most apis treat ?foo like ?foo= or ?foo=true but there are apis that treat ?foo= like ?foo=false.
Yes clients probably should give query args explicit values but sometimes you want to use or test an api with a specific url, and httpx should let you construct any legal url.

This is the current requests-compatible but imo undesirable behavior:

$ python3
>>> import json
>>> import httpx
>>> payload = {'key1': 'value1', 'key2': None, 'key3':''}
>>> r = httpx.get('https://httpbin.org/get', params=payload)
>>> print(json.dumps(r.json(), indent=4))
{
    "args": {
        "key1": "value1",
        "key2": None,
        "key3": ""
    },
...
    "url": "https://httpbin.org/get?key1=value1&key2=&key3="
}

Desired behavior:

...
    "url": "https://httpbin.org/get?key1=value1&key2&key3="
}

[lovelydinosaur]

I'm not 100% against differentiating between None and "" in this way, but it's a pretty subtle distinction.

The alternate approach is to include query params directly on the URL string, eg...

r = httpx.get('https://httpbin.org/get?key2')

On the basis of emoji responses to this comment... psf/requests#2651 (comment) ...it seems like there's a decent bit of support for this.

The details are likely to be far more fiddly that you might suspect at first. For example, the type signatures of various methods on QueryParams would change. For example, this one...

httpx/httpx/_models.py

Line 484 in eb7433b

def get_list(self, key: typing.Any) -> typing.List[str]:

...would become...

def get_list(self, key: typing.Any) -> typing.List[Typing.Optional[str]]

Also implementation-wise it looks like it could well be unexpectedly gnarly. We lean on urllib.parse.parse_qsl to parse the query string when provided as a string...

https://github.com/encode/httpx/blob/eb7433bf8edc90f064adcaedfd4897f9c059d8d7/httpx/_models.py#L445

I don't think that has any way of differentiating between the ?flag= and ?flag cases.

[lovelydinosaur]

Not completely impossible that we could duplicate and modify parse_qsl to resolve this, but certainly a bit icky...

Relevant portion is here...

# Handle case of a control-name with no equal sign
if keep_blank_values:
     nv.append('')

[lovelydinosaur]

A sensible iterative approach here could be this...

Pre-1.0 we ensure that None values raise a hard TypeError if passed.

That then gives us the ability to extend into supporting "None values indicate no equals sign" at a later date, without breaking API compatibility. (Since we're extending our API that way, rather than changing an existing supported behaviour.)