Skip to content


Subversion checkout URL

You can clone with
Download ZIP


No way to add query parameters without a value #1119

wichert opened this Issue · 10 comments

6 participants


I occasionally need to put a hint in the query string for a URL, which is essentially a parameter without a value. This can be important to provide information to javascript or as a hint to GA. For example I may need to use http://localhost/dashboard?new-user as URL when I redirect a new user to the dashboard after completing registration.

Intuitively I expected this to work:

return HTTPFound(request.route_url('dashboard', _query={'new-user': None}))

but that returns /dashboard?new-user=None which is not very pretty.


I tested how each of these would flow back into request.GET.

It looks like ?new-user would flow into request.GET as an empty string, while ?new_user=None flows into request.GET as the string "None".

Getting the "None" back as a string doesn't seem all that intuitive. IMO this further strengthens the case for changing this behaviour in the encoding function.



Well any time you are using None outside of actual Python code, whether you think it's a good idea or not it's gonna be a string. Magically parsing a received string, checking if its equal to some magic constant, and converting it to some other value isn't something Pyramid is going to, or should, do for you automatically.

Anyway I agree that we can fix the generation of the URL to drop the value if it is None, causing an empty string on the parsing side. Do you want to submit a pull request, tests, and a doc update for this feature?

@mcdonc mcdonc closed this in #1131

Closed via #1131 (comment)


I don't agree this is fixed. #1131 makes it possible to generate a parameter with a empty value (?new-user=), which is not the same and not nearly as nice as a simple flag (?new-user).


I think that currently this is because we are attempting to conform to the strict parsing in urlparse.parse_qs

However I can't find any standard that states that query parameters have to be key=value pairs. See my comment here: #1131 (comment)


Just to revisit this, a question came up in IRC about generating a URL where the query string is not encoded using application/x-www-form-urlencoded. According to the RFCs there doesn't appear to be any issue here. Perhaps we want to either allow the None or simply allow _query to accept a pre-encoded string.

This is analagous to using request.body if the body is not a form-style encoding, where request.POST is invalid. In the context of query strings request.query_string is like the raw body, and request.GET only works for form-style encodings (<form method="get">).

Therefore I propose a compromise that _query should accept strings as well as dictionaries and lists of 2-tuples to allow generating query strings using arbitrary encodings. I'm happy to make this change if it pleases the committee.

@mmerickel mmerickel reopened this

I'm the one who raised the question, and I'll summarize what I posted over on the PR, since this is where discussion should take place (sorry for the noise).

I ran into this issue when trying to use Mapstraction, which requires generating URLs like, where a trailing (or leading) equals sign will break the parameter.

Having the option to generate query strings that are not application/x-www-form-urlencoded is useful, since they seem to be within the bounds of the RFC and are often used in practice. In my case, it's not just "not as nice", but the stray equals sign actually breaks Mapstraction, requiring me to use other methods to fill out the tag. urlparse.parse_qs doesn't parse such query strings in strict mode, but it deals with them handily with strict_parsing=0:

>>> cgi.parse_qs('a=1&b&c', keep_blank_values=0)
{'a': ['1']}
>>> cgi.parse_qs('a=1&b&c', keep_blank_values=1)
{'a': ['1'], 'c': [''], 'b': ['']}
>>> cgi.parse_qs('justvalue', keep_blank_values=0)
>>> cgi.parse_qs('justvalue', keep_blank_values=1)
{'justvalue': ['']}

The previously-applied solution of specifying None seems clean and intuitive to me, but @mmerickel's proposal to simply accept a string instead of a sequence of tuples is fairly intuitive as well.

I will note that I am coming into this as a user, who is just picking up Pyramid, and don't know of any possible complexities (e.g. any use of parse_qs within Pyramid itself). Just that as a developer using Pyramid, this seems like something that should be doable with static_url and company.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Something went wrong with that request. Please try again.