can i rely on the order of keys in a python dict in practice?

the specs says they are unspecified, but i think if it remains consistent it practice, it's legit to use

Python is open source, right? Can you look at how the dictionaries are implemented?

what got me thinking was implementing d.get(x,y) by instead adding an entry {x:y} to d

that's a good idea

I use Julia a lot and I find that browsing the source is quite illuminating when the docs are lacking.

@xnor I'm sure it's implementation-dependent, but I think I recall seeing something that said they're consistent in practice, at least for some particular version.

This really should have been called The Eighteenth Byte.

sources say it's implemented as a hash table, so it would make sense that it's consistent

Are hash tables always consistent?

@AlexA. Because it's more golfy than The Nineteenth Byte?

Haha I guess. I kind of like this name though.

@AlexA. i don't really know, but i'd guess that the table is at least consistent once it is generated

That would make sense. So there's still some uncertaintly but the evidence is mounting that dictionary keys would be reliably ordered.

Are you thinking Python 2 or 3?

every example i've tried so far has later entries obsolete earlier once

@AlexA. either one, but it would be good to know if there's version differences

Definitely.

If there are and they aren't documented, they should be.

i realized i might be conflating two different questions

which key/value pair takes precedence when a key is repeated

and the order in which keys are iterated over or converted to a list

the second seems arbitrary:

list(dict(zip(string.ascii_lowercase,range(26))))
=> ['a', 'c', 'b', 'e', 'd', 'g', 'f', 'i', 'h', 'k', 'j', 'm', 'l', 'o', 'n', 'q', 'p', 's', 'r', 'u', 't', 'w', 'v', 'y', 'x', 'z']

on the other hand:

list(dict(zip(range(26),string.ascii_lowercase)))
=> [0, 1, 2, 3, 4, 5, 6, 7, 8, 9, 10, 11, 12, 13, 14, 15, 16, 17, 18, 19, 20, 21, 22, 23, 24, 25]

(Python 2.7)

Python dictionary keys can be repeated?

you can repeat them, but when the dict is created, only one instance of each key is kept

I'm not sure I understand. Can you give an example?

{1:True,1:False}
=> {1: False}

Oh I see

Thanks

Isn't it the last that takes precendence when multiple values are specified for the last key just by virtue of how it's parsed?

that would make sense, it seems likely

ok, this makes me confident enough to suggest {x:y,...}[x] as a shorter version of {...}.get(x,y).

Going to add it to the Python golfing tips?

yup, writing it now

thanks for looking at this

My pleasure! I hope I was able to help because I don't feel like I did. Haha

In regards to the other related question, here's some interesting data:

list(dict(zip(string.ascii_lowercase,range(26))))
=> ['a', 'c', 'b', 'e', 'd', 'g', 'f', 'i', 'h', 'k', 'j', 'm', 'l', 'o', 'n', 'q', 'p', 's', 'r', 'u', 't', 'w', 'v', 'y', 'x', 'z']

list(dict(zip(string.ascii_lowercase[::-1],range(26))))
=> ['a', 'c', 'b', 'e', 'd', 'g', 'f', 'i', 'h', 'k', 'j', 'm', 'l', 'o', 'n', 'q', 'p', 's', 'r', 'u', 't', 'w', 'v', 'y', 'x', 'z']

But not in Python 3:

list(dict(zip(string.ascii_lowercase,range(26))))
=> ['b', 'e', 'k', 'u', 'r', 'n', 'p', 'v', 'j', 'l', 'h', 'x', 'f', 'i', 'y', 't', 'w', 's', 'a', 'g', 'o', 'c', 'd', 'm', 'z', 'q']

list(dict(zip(string.ascii_lowercase[::-1],range(26))))
=> ['i', 'g', 'x', 'k', 'q', 'u', 'r', 'n', 'p', 'v', 'b', 'j', 'f', 'z', 'y', 't', 'e', 'w', 's', 'm', 'l', 'o', 'c', 'd', 'h', 'a']

interesting

That's... I have no idea what to think of that.

So it appears that there's more of a pattern to things in Python 2.

does Python 3 at least give the same thing for the same expression evaluated twice?

Yes, as far as I've tested it.

(I'm using 3.5.0--not sure if this is a 2 vs 3 difference or more recent.)

i get your python 2 result in 3.2.2

with the exact same order

(Why is your Python 3 so old? ._.)

Yeah, okay. Maybe Python release notes was where I remember seeing something about this.

not having updated it since i downloaded it

here's the tip i wrote: codegolf.stackexchange.com/a/61529/20260

@DLosc I get something different than this in Python 3.4.2

>>> list(dict(zip(string.ascii_lowercase,range(26))))
['k', 'a', 'i', 'n', 'r', 'b', 'm', 'h', 't', 'y', 'l', 'z', 'o', 's', 'p', 'x', 'd', 'e', 'g', 'v', 'q', 'f', 'w', 'u', 'c', 'j']

When I close Python and restart it, then submit the same command, I get a different order.

Ahh. Interesting. Let me try that...

i think we've seen similar results with set

@AlexA. Same.

list(set(string.ascii_lowercase))
['a', 'c', 'b', 'e', 'd', 'g', 'f', 'i', 'h', 'k', 'j', 'm', 'l', 'o', 'n', 'q', 'p', 's', 'r', 'u', 't', 'w', 'v', 'y', 'x', 'z']

(3.2.2)

@DLosc But I always get the same order with 2.7.6.

@xnor I get the same thing with 2.7

it's weird that it's ordered except the last bit is flipped

numbers seems to preserve order though:

>>> R=list(range(100000));list(set(R))==R
True

never mind, numbers sort?

>>> list(set(range(10)[::-1]))
[0, 1, 2, 3, 4, 5, 6, 7, 8, 9]

I feel like we need to get a Python dev in here.

I find this all quite bizarre.

Grr... I'm positive I've seen something about this very topic, but I can't find it now. It's not in any of the "What's New" documents for Python 3.3, 3.4, or 3.5.

Has 3.5 been released?

I have 3.5.0.

:O

I'm installing it right now.

A lot of the Julia features that could be (ab)used for golfing have been deprecated in 0.4. For example, in 0.3.11, the last release in the 0.3 line, one could do int("1") which would return the integer 1. The int function has been deprecated in 0.4 in favor of the constructor Int(), which doesn't accept a string argument. So now one has to do parse(Int,"1") rather than int("1"). :(

you can't just write 1?

Well yeah.

I mean if you're trying to extract an integer from a string.

It was just a toy example.

oh, i see

What's worse is that you used to be able to do int(["1","12","44"]) to get the array [1, 12, 44]. But now you need to do map(i->parse(Int,i),["1","12","44"]).

Ouch.

Yeah.

There's a similar situation in ActionScript between 2.0 and 3.0. In 2.0, one can still use chr(x); in 3.0, String.fromCharCode(x) is required.

Ohhhh that's rough

Not that Julia or ActionScript would ever win a code golf competition anyway. :P

They were trying to make it closer to ECMAScript standards, I think.

Ah, okay.