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

Matthew Wood woodm1979 at gmail.com
Sat May 29 09:24:12 CEST 2010


On Fri, May 28, 2010 at 6:55 PM, Steven D'Aprano <steve at pearwood.info>wrote:

> 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
> _______________________________________________
> Tutor maillist  -  Tutor at python.org
> To unsubscribe or change subscription options:
> http://mail.python.org/mailman/listinfo/tutor
>


Well, since it appears that my offer to nip the email flame-war in the bud
was declined, I'll reluctantly respond.

And as name dropping Alex Martelli seems the order of the day, I'll go ahead
and share my experience with him as well: He decided to put my code into the
python cook book (for those that demand citations: Python Cookbook, 1st
edition, recipe 2.7, page 49).  He did so while making suggestions on how my
code could be improved in many ways, including efficiency and correctness.
He made those suggestions in a very professional, and classy manner, as can
be seen in the text of the book.

That's all I'm really asking for here.  I'm 100% sure I made a
version-reference mistake.  I'm also 100% sure you recognized that I made a
version-reference mistake.  Neither of those facts are in dispute here.  In
fact, it's very important, in the context of a tutoring medium like this
email list, that someone point out the mistakes made by others.  In other
words, constructive criticism is extremely important and very appropriate
here, and indeed most every situation.  I both give and receive constructive
criticism on a daily if not hourly basis.

But your response was neither professional, nor classy.  At the very least,
it was over the top.  Nowhere in Alex's response to me did he insult me,
accuse me of "cargo-cult programming" or "programming without understanding
what I'm doing", nor use any other insulting/diminishing phrase.  He simply
mentioned the ways my code could/should be improved, and showed a better
example.

In conclusion, I've remembered the "dress, sort, undress" idiom for sorting
data by attribute ever since.  So yes, even when someone is classy,
professional, and dare I say nice, messages are be learned.


I hope you have a great weekend.

--  Matthew Wood

I enjoy haiku
but sometimes they don't make sense;
refrigerator?
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/tutor/attachments/20100529/e7d46c3b/attachment-0001.html>


More information about the Tutor mailing list