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