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