[lovelydinosaur]

Allow primitive data types for query params.

Closes #154

[lovelydinosaur]

Later follow ups:

• Allow typing.Union[PrimitiveData, typing.List[PrimitiveData]] for eg. {a: [1, 2, 3]} => a=1&a=2&a=3
• Use same style for urlencoded and multipart data.
• Strictly enforcing types (TypeErrors against public interfaces. #122)
• Nailing down exactly which composite types we want to enforce against. eg. For the list case, do we want typing.List, typing.Sequence, typing.Iterable. For the dict case, do we want typing.Mappingortyping.Dict`. Related to TypeErrors against public interfaces. #122.
• Perhaps handle Decimal, Date, Time, DateTime, UUID?

Let's treat those as separate issues.

[lovelydinosaur]

Thanks for the look-over, @pquentin!

[sethmlarson]

Sorry for not getting my review in on this! This implementation can't emit a query key without a value (ie: ?q, different than an empty value ?q=)

[lovelydinosaur]

This implementation can't emit a query key without a value (ie: ?q, different than an empty value ?q=

Yup. I’m very okay with that - I don’t think we should distinguish between the two cases, although I’d be happy with confirming which of the two styles browser form inputs end up with. If users need that use case for something esoteric, then they can use explicit string query strings.

[cansarigol]

are there any obstacles to using PrimitiveData? for consistency

[lovelydinosaur]

Yes and no. We'd need some tweaking to avoid a cyclical dependency.

[StephenBrown2]

Following up on my comment last week, turns out the API I'm implementing a client for dies if the optional param is present whether or not the key has an = after it, so roundtripping is the only sane way for me. ☝️ looks good to me though!