Re: QueryDict and its .dict() method - why does it do that?

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQIcBAEBCAAGBQJVFbSfAAoJEC0ft5FqUuEhveIQAIaClYCrAQzVjp/6UZ7iEahG
PUvmdOk+700I5QZMKwWx/zPYvFhkGnAvsQ0fkk3j520O9u0oISrBCJ7v9QTvBd7v
vL99gbHmtTI0z6BwLLOG5t33igfIc+LnGwKR3mN7OPlU1VZtFbHrANu2Bo/zBp5S
oUYkSRryHutC1oqi48uXVNDRyj+mDBavUW+PXZCGfsZ3eW27jwmtpk94x+l/tsnH
NXe0jbDyZl87OIJpj/g7aPUQfcu6DEFztjwa6HJurYdcWhV8HLPAnlkFRC7qCZ/g
WFMqojek/T5Qq2ZQTudc/vCBQ4cvJo0ZHysDYZM57+EWrnzyKFIrc43YzlDfjIAH
hNzqQ4s0ghjESH4PMYVXyg1Up+fEEmuQLpFj0k09TQoVwRoCX6XTm/fqHk17Srxe
RyZuT7gbguBPyi5pQ3I7FctyvpQF3ifU4D5bcWcxbDiEUUiD3kMlZDP+2YLr4IbR
zECfTbqtVCfIl/IGNMJHF/pq1N4qYvuPM3pZFtJdUZrmFw8w/gzYx/SCdYbmcR3N
FZtKV6L1k6O0AmcjfPV8lq8HEBPoFknqCApNNZISaZyDcfFIey+qxx0bIGby5oLy
270+j0/NsTU+UoN8kyjuqDbfl+NY/56fbeTPTd1hr7+wGq+5XRtv2HguKZfcblYn
uiDUJpRL5ARcv5+9N9Xz
=iQCg
-----END PGP SIGNATURE-----
Hi Gabriel,

On 03/27/2015 01:34 PM, Gabriel Pugliese wrote:
> @Masklinn
> That input is from jQuery's default serializer. It sends the data with
> contentType 'application/x-www-form-urlencoded; charset=UTF-8'. I just
> need to pass a data parameter with my JS Object (JSON) and it does the
> magic.

Yes, jQuery has chosen to adopt the same non-standard that Rails and PHP
use for smuggling nested lists and objects through a flat querystring.

> I understand I can use .getlist() or any other non-optimal solution.

request.GET.getlist('key') is the correct solution in Django for getting
a list of values from a querystring.

> I
> also understand what's going on about keys here (that's why I asked
> about laziness nature of QueryDict).

I don't understand what you think is lazy about a QueryDict, or how that
would be related to this issue. QueryDicts are not lazy; they parse the
querystring immediately on instantiation.

> But following DRY, KISS and other
> philosophies, couldn't Django do the same as other frameworks assuming
> it's widely adopted that way? What is the advantage of doing things so
> differently about that?

Django's philosophy here follows KISS. We give you the querystring in a
parsed format that allows you to easily get the data out of it by the
actual key names found in the querystring. We don't assume that you are
using jQuery on the client side, and we don't add any magical
non-standard features to smuggle nested objects through the querystring.
Such behavior might "do the expected thing" for some new users of
Django, at the expense of being very confusing to other new users of
Django, who understand HTTP and HTML but haven't been exposed to the
jQuery/Rails/PHP behavior.

> Why should I need to implement a lib that re-iterates over the same
> string that QueryDict already parses

You don't need to go back to the raw querystring. It would not be hard
to implement a small function that would take a QueryDict, iterate over
it and interpret it in the jQuery/Rails/PHP style, and return a
dictionary. I'd guess that someone may have already done this, though
I'm not sure what terms I'd use to search for it. If nobody has, then
you could be the first! Put it on PyPI, advertise it, and see what kind
of demand there is.

> to achieve the result that is
> expected to everyone that is new to Django?

I am a counter-example to your assertion that the Rails/PHP/jQuery
behavior is "expected to everyone that is new to Django." I had never
heard of the Rails/PHP/jQuery behavior when I was new to Django, and
Django's handling made perfect sense to me. The first time I ran across
jQuery's behavior, I was very confused.

> Anyway, thanks for the clear answer and information. And sorry about any
> grammar errors, English is not my first language.

No problem. I hope my answer was clear and informative.

Carl

--
You received this message because you are subscribed to the Google Groups "Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email to django-users+unsubscribe@googlegroups.com.
To post to this group, send email to django-users@googlegroups.com.
Visit this group at http://groups.google.com/group/django-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/django-users/5515B49F.3010603%40oddbird.net.
For more options, visit https://groups.google.com/d/optout.