[Tutor] list of dicts <-> dict of lists?

[Steven D'Aprano]

On Fri, 28 May 2010 12:00:46 pm Matthew Wood wrote:

> I THOUGHT the guaranteed same-ordering of dict.keys and dict.values
> started in python 2.6.  That was a simple mistake.
>
> It turns out, that's not the case.  But in general, access to dicts
> and sets is unordered, so you can't/don't/shouldn't count on
> ordering.

You can't count on getting a *specific* order, but you can count on 
getting a *consistent* order. (So long as you don't modify the 
dictionary between calls, of course.)


> The solution to take keys and values from dict.items() 
> DOES guarantee their ordering, even if dict.keys and dict.values
> aren't.

And so does zip(d.keys(), d.values()). They both guarantee the same 
consistent ordering.

The fact is, yes, your solution does work, but your rationale for 
preferring it is irrational. That's not meant to be insulting, we all 
have preferences based on irrational little quirks, we wouldn't be 
human otherwise. When there are two equally good solutions, you have to 
pick one or the other for essentially an irrational reason -- if there 
was a rational reason to prefer one over the other, they wouldn't be 
equally good.

If you choose to continue using the dict.items() solution, by all means 
do so because you like it, or because it gives you a warm fuzzy 
feeling, or because it's easier for you to remember. Or because you've 
profiled it and it is 3% faster or uses 1% less memory (I made those 
numbers up, by the way). These are all good reasons for choosing a 
solution over another solution.

But stop trying to justify it on the basis of it being safer and more 
backwards compatible, because that's simply not correct. That's what 
pushes your solution out of personal preference to cargo-cult 
programming: following the form without understanding the semantics. 
The semantics of dict.keys() and values() guarantee the same order.


[...]
> But imagine if that guaranteed behavior started in 2.5 for example. 
> Then, if you want your code to work on 2.3, you'd definitely want to
> pull them out of the dict via dict.items().

But it didn't start in 2.5. It has been part of Python essentially 
forever. If I argued, "Imagine that dictionaries only gained an items() 
method in 2.5, and you wanted it to work in 2.3, you'd need to avoid 
dict.items()", what would you say?


> I think your response was quite rude.

If you can't take constructive criticism without getting offended and 
crying "oh how rude!", there's a serious problem.


> I mean really, cargo cult programming?
> I just tried to suggest a solution and I think it's crappy that you
> accused me of "programming without understanding what you are doing".

I think it is quite clear that in *this* specific case you don't 
understand what you are doing, because you are recommending a solution 
that you labelled "This line isn't necessary". If it's not necessary, 
why include it?

We all code badly at times. I'm sure if you were to go through my code 
line by line, you'd find some real clangers caused by me failing to 
fully understand what I was doing too. Patches and bug reports are 
welcome :)

If it makes you feel any better, I was once told by Alex Martelli (one 
of the Python demi-gods) that if he were marking my code for an 
assignment he would fail me over what I believed was a trivial 
stylistic difference of opinion. I was declaring globals even if I 
didn't assign to them, e.g.:

def func(x):
    global y
    return x + y

It took me a long time, perhaps a few years, but I've come around to 
Martelli's position on globals and no longer declare them unless I 
assign to them. I still think a fail over such a small issue is awfully 
harsh, but perhaps he was having a bad day. I've come to understand the 
semantics of the global statement better, and can see that unnecessary 
global declarations goes against the purpose and meaning of the 
statement. I was, in short, cargo-cult programming, using global 
without understanding it. As harsh as Martelli's response was, I 
believe I'm a better coder today because of it than if he had just 
patted me on the head and said "that's okay, you write anything you 
like".



-- 
Steven D'Aprano