Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #25850 > unrolled thread

dict: keys() and values() order guaranteed to be same?

Back to article view | Back to comp.lang.python

Contents

  dict: keys() and values() order guaranteed to be same? Henrik Faber <hfaber@invalid.net> - 2012-07-23 13:23 +0200
    Re: dict: keys() and values() order guaranteed to be same? Philipp Hagemeister <phihag@phihag.de> - 2012-07-23 13:40 +0200
      Re: dict: keys() and values() order guaranteed to be same? Henrik Faber <hfaber@invalid.net> - 2012-07-23 14:19 +0200
    Re: dict: keys() and values() order guaranteed to be same? Stefan Behnel <stefan_ml@behnel.de> - 2012-07-23 13:43 +0200
    Re: dict: keys() and values() order guaranteed to be same? Stefan Behnel <stefan_ml@behnel.de> - 2012-07-23 13:58 +0200
      Re: dict: keys() and values() order guaranteed to be same? Steven D'Aprano <steve+comp.lang.python@pearwood.info> - 2012-07-23 15:20 +0000
        Re: dict: keys() and values() order guaranteed to be same? Chris Angelico <rosuav@gmail.com> - 2012-07-24 02:18 +1000
        Re: dict: keys() and values() order guaranteed to be same? Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 14:06 -0700
        Re: dict: keys() and values() order guaranteed to be same? Ethan Furman <ethan@stoneleaf.us> - 2012-07-26 14:03 -0700

#25850 — dict: keys() and values() order guaranteed to be same?

Hi group,

I have a question of which I'm unsure if the specification guarantees
it. With an arbitrary dictionaty d, are d.keys() and d.values()
guaraneed to be in the same order? I.e. what I mean is:

# For all dictionaries d:
assert({ list(d.keys())[i]: list(d.values())[i] for i in range(len(d)) }
== d)

I'm curious if it's allowed because in a special case it would make for
a nice shortcut and clean code. I think however that the implementation
may chose not to have them in the same order necessarily -- then I'd
obviously avoid relying on it.

Best regards,
Joe

[toc] | [next] | [standalone]

#25851

[Multipart message — attachments visible in raw view] — view raw

On 07/23/2012 01:23 PM, Henrik Faber wrote:
> With an arbitrary dictionaty d, are d.keys() and d.values()
> guaraneed to be in the same order?

Yes. From the documentation[1]:

If items(), keys(), values(), iteritems(), iterkeys(), and itervalues()
are called with no intervening modifications to the dictionary, the
lists will directly correspond.

In most cases, you should simply use items() though. Can you elaborate
on the use case for needing both keys() and values(), where items() is
not applicable?

- Philipp

[1] http://docs.python.org/library/stdtypes.html#dict.items

[toc] | [prev] | [next] | [standalone]

#25855

On 23.07.2012 13:40, Philipp Hagemeister wrote:
> On 07/23/2012 01:23 PM, Henrik Faber wrote:
>> With an arbitrary dictionaty d, are d.keys() and d.values()
>> guaraneed to be in the same order?
> 
> Yes. From the documentation[1]:
> 
> If items(), keys(), values(), iteritems(), iterkeys(), and itervalues()
> are called with no intervening modifications to the dictionary, the
> lists will directly correspond.

Ah, nice!

> In most cases, you should simply use items() though. Can you elaborate
> on the use case for needing both keys() and values(), where items() is
> not applicable?

I need to parse and modify the keys of the dict and pass the keys as a
compound object to a function, which expects the values to be passed as
an argument list (weird, but can't change that). The order of arguments
is arbitrary (as the iteration over a dict is), but there has to be a
1-to-1 relation bewtween the compound object's key order and the
argument list's value order.

Best regards,
Henrik

[toc] | [prev] | [next] | [standalone]

#25852

Henrik Faber, 23.07.2012 13:23:
> I have a question of which I'm unsure if the specification guarantees
> it. With an arbitrary dictionaty d, are d.keys() and d.values()
> guaraneed to be in the same order? I.e. what I mean is:
> 
> # For all dictionaries d:
> assert({ list(d.keys())[i]: list(d.values())[i] for i in range(len(d)) }
> == d)
> 
> I'm curious if it's allowed because in a special case it would make for
> a nice shortcut and clean code. I think however that the implementation
> may chose not to have them in the same order necessarily -- then I'd
> obviously avoid relying on it.

You should.

Stefan

[toc] | [prev] | [next] | [standalone]

#25854

Philipp Hagemeister, 23.07.2012 13:40:
> On 07/23/2012 01:23 PM, Henrik Faber wrote:
>> With an arbitrary dictionaty d, are d.keys() and d.values()
>> guaraneed to be in the same order?
> 
> Yes. From the documentation[1]:
> 
> If items(), keys(), values(), iteritems(), iterkeys(), and itervalues()
> are called with no intervening modifications to the dictionary, the
> lists will directly correspond.
> 
> [1] http://docs.python.org/library/stdtypes.html#dict.items

Interesting. I wonder if other implementations like Jython and PyPy really
adhere to this official guarantee. At least Jython has the same paragraph
in its documentation and I would expect that PyPy follows it as well.

http://www.jython.org/docs/library/stdtypes.html#mapping-types-dict

Maybe this guarantee is just easy enough to build on the given
implementation details of a platform that it's a common property. Iteration
over data structures should tend to be deterministic, after all.

Stefan

[toc] | [prev] | [next] | [standalone]

#25887

On Mon, 23 Jul 2012 13:58:37 +0200, Stefan Behnel wrote:

> Philipp Hagemeister, 23.07.2012 13:40:
>> On 07/23/2012 01:23 PM, Henrik Faber wrote:
>>> With an arbitrary dictionaty d, are d.keys() and d.values() guaraneed
>>> to be in the same order?
>> 
>> Yes. From the documentation[1]:
>> 
>> If items(), keys(), values(), iteritems(), iterkeys(), and itervalues()
>> are called with no intervening modifications to the dictionary, the
>> lists will directly correspond.
>> 
>> [1] http://docs.python.org/library/stdtypes.html#dict.items
> 
> Interesting. I wonder if other implementations like Jython and PyPy
> really adhere to this official guarantee.

If they want to claim to be implementations of Python, as opposed to 
merely some Python-like language with identical syntax but different 
behaviour, then they better adhere to it. If they don't honour the 
language promise, then they are buggy.


[...]
> Maybe this guarantee is just easy enough to build on the given
> implementation details of a platform that it's a common property.

Easy or hard, it is a promise of the language.

(Although if you think about the implementation of dicts as hash tables, 
it does seem likely that it is trivial to enforce this -- one would have 
to work *harder* to break that promise than to keep it.)


> Iteration over data structures should tend to be deterministic, after
> all.

Deterministic is not a very strong promise. The order of iteration of 
dict.keys() is deterministic but not easily predictable, since it depends 
on the history of the dictionary. The output of random.random() is 
deterministic but (pseudo-)random.

Python's promise is much stronger than merely "deterministic": while it 
does not promise what order the keys will be returned, it does promise 
that whatever that order turns out to be, they will returned in the same 
order as the matching values (unless you modify the dict while iterating).



-- 
Steven

[toc] | [prev] | [next] | [standalone]

#25899

On Tue, Jul 24, 2012 at 1:20 AM, Steven D'Aprano
<steve+comp.lang.python@pearwood.info> wrote:
> (Although if you think about the implementation of dicts as hash tables,
> it does seem likely that it is trivial to enforce this -- one would have
> to work *harder* to break that promise than to keep it.)

However, it would be quite reasonable to implement a dict as a splay
tree, and have values() return them nearest-first. This would mean
that just reading from the dictionary could change the order of
values(), yet it wouldn't make the implementation non-conformant.

Of course, if I want splay tree semantics, I'd rather explicitly ask
for that. But it'd be legal.

ChrisA

[toc] | [prev] | [next] | [standalone]

#26115

Chris Angelico wrote:
> On Tue, Jul 24, 2012 at 1:20 AM, Steven D'Aprano
> <steve+comp.lang.python@pearwood.info> wrote:
>> (Although if you think about the implementation of dicts as hash tables,
>> it does seem likely that it is trivial to enforce this -- one would have
>> to work *harder* to break that promise than to keep it.)
> 
> However, it would be quite reasonable to implement a dict as a splay
> tree, and have values() return them nearest-first. This would mean
> that just reading from the dictionary could change the order of
> values(), yet it wouldn't make the implementation non-conformant.

Yes, it would.  The docs say that .keys(), .values(), etc., will 
maintain order unless the dict is modified in between calls.

~Ethan~

[toc] | [prev] | [next] | [standalone]

#26117

Steven D'Aprano wrote:
> Python's promise is much stronger than merely "deterministic": while it 
> does not promise what order the keys will be returned, it does promise 
> that whatever that order turns out to be, they will returned in the same 
> order as the matching values (unless you modify the dict while iterating).

or modify the dict between iterations.

~Ethan~

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web