QueryDict and ordering

[Ole Laursen]

Hi!

Would it be possible to derive QueryDict (i.e. MultiValueDict) from an OrderedDict instead of dict?

I'm finding it increasingly irritating that the original order is kept by the whole stack right until Django puts it into a dict. It makes some highly dynamic form situations more tedious to handle.

Now that Python 3.6 preserves the order of dicts as an implementation detail, there should not be any performance overhead as far as I'm aware.

Ole

[Tim Graham]

Hi, Did you try writing a patch? I naively tried "class MultiValueDict(OrderedDict):" as the only change and it doesn't pass the tests. Perhaps more adaptations are required.

As for the motivation, I'm not sure if you described the problem in enough detail. (i.e. what does "It makes highly dynamic form situations more tedious to handle" mean?)

If Python 3.6 preserves order, is this only an issue on Python 3.5? If so, I'd guess there would be little motivation in making a change (if it's a non-trivial change) given 3.5 will be end-of-life soon enough (2020).

[Ole Laursen]

2018-01-05 17:12 GMT+01:00 Tim Graham <timog...@gmail.com>:
> Hi, Did you try writing a patch? I naively tried "class
> MultiValueDict(OrderedDict):" as the only change and it doesn't pass the
> tests. Perhaps more adaptations are required.

Tried just now, and yeah it takes a little more adaptation.
MultiValueDict is relying on __setitem__ not being called by the
underlying dict implementation in a couple of places, e.g.
MultiValueDict({ "foo": [ "bar"] }). I'm happy to write a little patch
if the idea makes sense.

> As for the motivation, I'm not sure if you described the problem in enough
> detail. (i.e. what does "It makes highly dynamic form situations more
> tedious to handle" mean?)

If you are using Javascript to insert extra forms or rearrange input
fields, and the order matters, then you can't use request.POST without
some kind of bookkeeping workaround. Either by encoding and
maintaining a sequence number client-side, or by adding extra fields
to handle it.


For instance, I have a bunch of rows like this where rows can be
rearranged by dragging:

Foo: 1___ Bar: hello______ [x]

Foo: 3___ Baz: [ Choice 1 ] [x]

[Add row]

I'm using a form to validate each row - so each have a name prefix.
Ideally, I could just go through request.POST.keys(), look for each
new set of values and instantiate forms as needed.

> If Python 3.6 preserves order, is this only an issue on Python 3.5? If so,
> I'd guess there would be little motivation in making a change (if it's a
> non-trivial change) given 3.5 will be end-of-life soon enough (2020).

Unfortunately, it's only preserved as an implementation detail, if you
write code that depends on the order being preserved, then you need to
derive from OrderedDict. There was a thread on the Python list, and
you can see here

https://docs.python.org/3.6/whatsnew/3.6.html

that they're careful not to say that dict preserves the order.


Ole

[Tim Graham]

Preservation of dict ordering is guaranteed in Python 3.7+ so that officially fixes this, correct?
https://mail.python.org/pipermail/python-dev/2017-December/151283.html

[Todor Velichkov]

Is this what you are looking for?

from django.http import QueryDict
from collections import OrderedDict

class OrderedQueryDict(QueryDict, OrderedDict):
    pass

my_dict = OrderedQueryDict(request.META['QUERY_STRING'])

print my_dict.items()

[Ole Laursen]

2018-01-05 19:24 GMT+01:00 Tim Graham <timog...@gmail.com>:
> Preservation of dict ordering is guaranteed in Python 3.7+ so that
> officially fixes this, correct?
> https://mail.python.org/pipermail/python-dev/2017-December/151283.html

Sure, I can wait for that. Sorry for the noise, I should read that
list more often.


Ole