Allow templatetag `querystring` to start from an empty state

[Sjoerd Job Postmus]

The documentation for querystring starts with

Outputs a URL-encoded formatted query string based on the provided parameters.

But the current functionality is mostly limited to taking an existing mapping; modifying that in-place, and *then* rendering that as a querystring. (it defaults to request.GET if no mapping is provided).

When constructing an update for the querystring of the current view; this feels natural. When constructing the querystring of a different view (e.g.: a detail page where an attribute is rendered as a clickable link to some list filtered by that value), the current querystring is not relevant.

Use-case:

Instead of writing

    <a href="{% url 'product_list' %}?vendor={{ vendor.pk|unlocalize}}">{{ vendor.name }}</a>

I would like to be able to write

    <a href="{% url 'product_list' %}{% querystring None vendor=vendor.pk %}">{{ vendor.name }}</a>

(Note; the savings will be a lot better if there is more than 1 querystring parameter)

The change to the querystring would be reasonable minimal; and it would unlock an easier way of writing querystrings in more scenarios than currently available.

A workaround may be to create an empty dictionary, and provide that either via the context or a contextprocessor; but I feel that's less natural than just being able to write 'None' for starting with an empty dictionary.

If accepted; I would be happy to pick up the development.

[Natalia Bidart]

Thanks for the report and the detailed write-up. The use case is understandable, but this is a new feature rather than a bug, and the bar for extending built-in template tags is high, especially when the same result is achievable at the project level with very little code. A custom template tag wrapping querystring without the request.GET default is trivial to write using simple_tag:

from django.template.defaulttags import querystring

@register.simple_tag(takes_context=True)
def clean_querystring(context, **kwargs):
    return querystring(context, {}, **kwargs)

This reuses querystring entirely and can be tailored to each project's naming and behavior preferences. Marking as needsnewfeatureprocess, if there is broader community interest, please shepherd this through the new feature ideas GitHub project per the contributing guidelines (​https://docs.djangoproject.com/en/dev/internals/contributing/bugs-and-features/).