Correct query loss when using parse_qsl to dict

[dhermes]

NOTE: I noticed this when doing a fairly comprehensive source check to find the httplib2 footprint (for #128).

The issue is that repeated params could just be dropped:

>>> from six.moves import urllib
>>> params_list = urllib.parse.parse_qsl('a=1&a=2')
>>> params_list
[('a', '1'), ('a', '2')]
>>> dict(params_list)
{'a': '2'}

[theacodes]

This LGTM, but I wonder if there's not already something that handles this well?

[dhermes]

I just did git grep parse_q. It's crazy it was used incorrectly in 4 different places.

[dhermes]

@jonparrott I want to hold off on the merge until @nathanielmanistaatgoogle weighs in

[theacodes]

@dhermes good plan. This seems like hackery I'm not sure I like.

[dhermes]

This seems like hackery I'm not sure I like.

What is "this"?

[theacodes]

Doing urlparsing and such.

[dhermes]

Yeah I dunno. You can file an issue to follow-up?

[theacodes]

Just more to think about before we close #128 I think.

[dhermes]

Currently typing one-handed w/baby in my arms, can you add a checkbox about it in the long desc. for #128 for me?

[theacodes]

I read that as "typing with baby arms". :D

Will do.

[dhermes]

@nathanielmanistaatgoogle PTAL.

In particular, we should resolve what we think the actual goal of all those dict(parse_qsl(...)) calls were.

[nathanielmanistaatgoogle]

Agreed that this needs a deeper look; probably site-by-site (luckily there are few). Replace-except-if-the-value-is-a-list-of-two-or-more-then-add is just weird semantics.

If it's the case that all sites in the library are correct with replace semantics, then our library-private _helpers module should make available a helper function that implements replace semantics.

If it's the case that all sites in the library are correct with add-to semantics, then our library-private _helpers module should make available a helper function that implements add-to semantics.

If it's the case that some sites in the library are correct with replace semantics and some are correct with add-to semantics, then our library-private _helpers module should make available a helper function that implements replace semantics and a helper function that implements add-to semantics.

I seriously doubt that it's the case that there's a site in the library where the correct semantics are replace-except-if-the-value-is-a-list-of-two-or-more-then-add.

Am I making sense?

[dhermes]

Yes. But the issue with replace is if the original had multiple values, then what does replace mean? Which is why I suggested we first verify that each parameter shows up exactly once, then replace.

i.e. a=1&b=2 replace b=3 (or c=3) is easy but what if the original was b=1&b=2

[nathanielmanistaatgoogle]

For private helper methods, replace means what we implement it to mean. I could see it going one of two ways: either "replace" semantics mean "associate this key with this value, no matter whether zero, one, two, or more values were associated with the key previously" or "replace" semantics mean "associate this key with this value, and if there were zero values with the key previously, that's fine, and if there was one value with the key previously, that's also fine, but if there were two or more values associated with the key previously, that's a problem so raise an exception". While either of these choices would be acceptable to be blessed as correct, I suspect it's the first that is going to be more useful and applicable in our codebase. Is my suspicion correct?

[dhermes]

@nathanielmanistaatgoogle Hopefully this works. Don't forget to remind me to squash on LGTM

[nathanielmanistaatgoogle]

Looks good (after out-of-band discussion); squash and merge.