QueryDict.iteritems behaves differently than QueryDict.items

[Jure Vrscaj]

I found the ticket for this strange behaviour of QueryDict, which
meant I wasn't alone having a problem with it - http://code.djangoproject.com/ticket/7331,
and submited a patch.

It's actually MultiValueDict that is the cause, but let's clarify
things a little, first.

Consider this scenario:

>>> from django.http import QueryDict

>>> qd = QueryDict("a=1&b=2")
>>> qd.items()
[(u'a', u'1'), (u'b', u'2')]

>>> d = {}
>>> d.update(qd)
>>> d.items()
[(u'a', [u'1']), (u'b', [u'2'])]

Updating a dict with QueryDict as input results in having dict's
values converted to lists, which is broken IMO. The issue is with
MultiValueDict.iteritems() behaving differently than
MultiValueDict.items(). One yields lists, while the other returns
normal values.

Could this be fixed in 1.0? It breaks compatibility, I know.

regards,
jure

[Ludvig Ericson]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

On Jul 4, 2008, at 00:45, Jure Vrscaj wrote:

> Could this be fixed in 1.0? It breaks compatibility, I know.

Although I'm not in any kind of position of making such a decision, I
can make an educated guess: no. The reason is that most developers
currently focus on getting a Django 1.0 out the door, and so there'll
be little to no time for a core committer to actually look at the
patch and commit it, adding tests and that.

That said, you should *definitely* file a bug report, and attach a
patch that fixes the misbehavior and also add a regression test. Doubt
there'll be any docs needed for this.

Also, what compatibility does it break? I can't see how this is a
common use-case.

Regards,
Ludvig "toxik" Ericson
ludvig....@gmail.com
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.8 (Darwin)

iEYEARECAAYFAkhtZp8ACgkQXnZ94Kd6KaettQCfbC6DfVjwbKj+1kcK4lXbnHs0
ar4AniFUpLSjQpe7PBjFnkluGqkSoJVS
=o0QH
-----END PGP SIGNATURE-----

[Malcolm Tredinnick]

On Fri, 2008-07-04 at 01:54 +0200, Ludvig Ericson wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> On Jul 4, 2008, at 00:45, Jure Vrscaj wrote:
>
> > Could this be fixed in 1.0? It breaks compatibility, I know.
>
>
> Although I'm not in any kind of position of making such a decision, I
> can make an educated guess: no. The reason is that most developers
> currently focus on getting a Django 1.0 out the door, and so there'll
> be little to no time for a core committer to actually look at the
> patch and commit it, adding tests and that.

We're always going to look at things like this. It's 10 minutes of
effort. :-)

Certainly file a ticket so that the information doesn't get lost, Jure.
The inconsistency looks a little wrong, although I'd have to think a bit
about which return type is the "right" one, since there are arguments
both ways.

Malcolm

[Jure Vrscaj]

> Also, what compatibility does it break? I can't see how this is a common use-case.

It might break existing code, code that depends on iteritems()
yielding lists. Maybe not a common use case, but it got me scratching
my head more than once.

On Jul 4, 7:40 am, Malcolm Tredinnick <malc...@pointy-stick.com>
wrote:

> Certainly file a ticket so that the information doesn't get lost, Jure.
> The inconsistency looks a little wrong, although I'd have to think a bit
> about which return type is the "right" one, since there are arguments
> both ways.

The ticket, patch and test is here: http://code.djangoproject.com/ticket/7331

Milestone is currently set to post-1.0, but I'd argue it's better to
fix it for 1.0, if at all.

Thanks for looking into it.

regards,
jure

[Tai Lee]

1.0 should ideally ship with Zarro Boogs, so any bugs (not DDN)
especially trivial ones with a patch including relavent tests / docs
should be marked for 1.0 milestone, I think ;)