-
Notifications
You must be signed in to change notification settings - Fork 429
Correct query loss when using parse_qsl to dict #622
Conversation
This LGTM, but I wonder if there's not already something that handles this well? |
I just did |
@jonparrott I want to hold off on the merge until @nathanielmanistaatgoogle weighs in |
@dhermes good plan. This seems like hackery I'm not sure I like. |
What is "this"? |
Doing urlparsing and such. |
Yeah I dunno. You can file an issue to follow-up? |
Just more to think about before we close #128 I think. |
Currently typing one-handed w/baby in my arms, can you add a checkbox about it in the long desc. for #128 for me? |
I read that as "typing with baby arms". :D Will do. |
@@ -199,12 +199,7 @@ def _add_query_parameter(url, name, value): | |||
""" | |||
if value is None: |
This comment was marked as spam.
This comment was marked as spam.
Sorry, something went wrong.
39c80dc
to
b9abeae
Compare
@nathanielmanistaatgoogle PTAL. In particular, we should resolve what we think the actual goal of all those |
b9abeae
to
717edcf
Compare
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 If it's the case that all sites in the library are correct with add-to semantics, then our library-private 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 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? |
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. |
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? |
ced809d
to
15033c1
Compare
@nathanielmanistaatgoogle Hopefully this works. Don't forget to remind me to squash on LGTM |
Looks good (after out-of-band discussion); squash and merge. |
af04323
to
ebe9ed0
Compare
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: