Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Python dicts are now ordered

softwaremaniacs.org

Post reply on HN
Print view View original

341–350 of 457 posts

Re: Python dicts are now ordered

#341

Post by xapata »

rcfox wrote: post #70
xapata wrote: post #66

Earlier quoted context omitted.

OrderedDict is less efficient. It's best to replace usage with basic dict where possible to improve efficiency. There is one obscure feature of OrderedDict that isn't in the basic, so it can't always be swapped.

Really? I would have figured they'd just do something like: class OrderedDict(dict): pass (Plus a little bit of API shimming.)

The builtins have some optimizations from the compiler and interpreter that Python-defined classes don't benefit from. The dict type especially so, because it's used to implement so many things.

Re: Python dicts are now ordered

#342

Post by coldtea »

kingdomcome50 wrote: post #278
skrebbel wrote: post #242

Earlier quoted context omitted.

Sure, PHP arrays are actually ordered maps, but it's super confusing when used as arrays. I mean, look at code like this: $arr = []; $arr[2] = "two"; $arr[0] = "zero"; $arr[1] = "one"; echo join($arr, ", "); // two, zero, one In any other language, the result of similar code would be "zero, one, two". You'd need to `ksort` this thing to get it to behave like a normal bog-standard boring array. Everybody's writing PHP…

I disagree. The behavior you exhibit makes more sense than the behavior you imagine. You start with an _empty_ array, then (somehow) set the third element of that array? That makes very little sense. Had you _initialized_ your example as an array with a length of 3, your desired behavior would, indeed, manifest.

>You start with an _empty_ array, then (somehow) set the third element of that array? That makes very little sense.

Well, there's no reason a language could not initialize an empty array to some initial capacity, either on declaration or when you add an indexed element.

Re: Python dicts are now ordered

#343

Post by coldtea »

lostcolony wrote: post #246
skrebbel wrote: post #223

This is awesome, because the ordered map is the best data structure out there for easy & predictable programming, possibly only barring the array. There's so many cases where it's a benefit for map entries to retain order (and none where it's a problem). PHP really got this one right (and immediately messed it up by mixing ordered maps with arrays into a big soup, but hey, PHP). And so did, JS, sorta-kinda-by-acciden…

>There's so many cases where it's a benefit for map entries to retain order (and none where it's a problem)' Don't know if this could actually be the case in practice, but theoretically the ordering could allow for a timing attack to glean some bit of information when performing a linear scan of the map (size of the map, relative location of the data, etc). Just a contrarian thought given the definitive statement of…

>Don't know if this could actually be the case in practice, but theoretically the ordering could allow for a timing attack to glean some bit of information when performing a linear scan of the map (size of the map, relative location of the data, etc).

An attack where the attacker has access to your ...program code and can run instructions there? In that case, leaks from a "timing attack" would be the least of your worries...

If they just provide an input to your program somehow externally, then whether you put that input into a map or an ordered map or not is an implementation detail. You could make your program rid of the "timing attack" in 100s of ways... (or have one, in 100s of ways). That doesn't make an ordered map more unsafe than any of the 1000s of ways to have a timing attack.

Re: Python dicts are now ordered

#344

Post by viraptor »

cdelsolar wrote: post #329
skrebbel wrote: post #242

Earlier quoted context omitted.

Sure, PHP arrays are actually ordered maps, but it's super confusing when used as arrays. I mean, look at code like this: $arr = []; $arr[2] = "two"; $arr[0] = "zero"; $arr[1] = "one"; echo join($arr, ", "); // two, zero, one In any other language, the result of similar code would be "zero, one, two". You'd need to `ksort` this thing to get it to behave like a normal bog-standard boring array. Everybody's writing PHP…

I literally just learned "bog-standard" 10 minutes ago and now I see it here. And no, don't Baader-Meinhof me, I would have noticed this weird term in random text in the past.

Would you though? Appears at least once a week: https://hn.algolia.com/?dateRange=all&page=0&prefix=false&qu...

Re: Python dicts are now ordered

#345

Post by miohtama »

inimino wrote: post #312
skrebbel wrote: post #223

This is awesome, because the ordered map is the best data structure out there for easy & predictable programming, possibly only barring the array. There's so many cases where it's a benefit for map entries to retain order (and none where it's a problem). PHP really got this one right (and immediately messed it up by mixing ordered maps with arrays into a big soup, but hey, PHP). And so did, JS, sorta-kinda-by-acciden…

> JS objects are ordered maps So currently (now that there are Symbols in JS), the order is: array-indexed properties first (integers), then string-key properties, in insertion order, then Symbol-keyed properties in insertion order. The reason for the funny behavior in treating integer keys differently is that property keys are always treated as strings, so obj["3"] and obj[3] can't be distinguished, and arrays are a…

I did not even know that integer is a good key for an object. Is this being used anywhere outside arrays?

Re: Python dicts are now ordered

#346

Post by AgentME »

d4lt wrote: post #279
styfle wrote: post #244

Earlier quoted context omitted.

Also don’t forget about JS Map which is ordered https://developer.mozilla.org/en-US/docs/Web/JavaScript/Refe...

Obligatory reminder: https://bugs.chromium.org/p/v8/issues/detail?id=164

That's not about JS Map objects, that's about regular objects which don't keep their properties in insertion order.

Re: Python dicts are now ordered

#347

Post by zepto »

cdelsolar wrote: post #329
skrebbel wrote: post #242

Earlier quoted context omitted.

Sure, PHP arrays are actually ordered maps, but it's super confusing when used as arrays. I mean, look at code like this: $arr = []; $arr[2] = "two"; $arr[0] = "zero"; $arr[1] = "one"; echo join($arr, ", "); // two, zero, one In any other language, the result of similar code would be "zero, one, two". You'd need to `ksort` this thing to get it to behave like a normal bog-standard boring array. Everybody's writing PHP…

I literally just learned "bog-standard" 10 minutes ago and now I see it here. And no, don't Baader-Meinhof me, I would have noticed this weird term in random text in the past.

Baader-Meinhof denial!

Re: Python dicts are now ordered

#348

Post by rovolo »

manaskarekar wrote: post #80
elcomet wrote: post #69

Earlier quoted context omitted.

That's not what people call backward compatibility. Backward compatibility is the ability to run old code with new interpreters. This is not broken here. What's broken is the ability to run new code on old interpreters. But this is already broken at every python update (new operators, methods, syntactic sugar..). We could call it reverse backward compatibility.

I suppose the meaning of the term depends on what we consider to be the subject of the compatibility. - backwards compatible code : new code can run on an old interpreter - backwards compatible interpreter : old code can run on a new interpreter EDIT: After some thought, you're right. The second description is the reasonable interpretation. "python 3.7 is backwards compatible with python 3.6"

This confusion reminds me of a scene from the 2002 film of Dave Barry's "Big Trouble".

(Driving to an airport) "Okay, we gotta pick a road. Arrivals or departures? We're arriving, but then we're departing."

https://en.wikiquote.org/wiki/Big_Trouble

https://www.youtube.com/watch?v=EjHHzZAUxbM&t=300

Re: Python dicts are now ordered

#349

Post by xxs »

masklinn wrote: post #245
dukoid wrote: post #174

Earlier quoted context omitted.

Java added LinkedHashMap a while ago. I tend to default to it except for small temporary use cases where order absolutely won't matter or have an outside impact...

LinkedHashMap is not Java's "standard maps" though. If you tend to use it by default it's really a personal idiosyncrasy, especially as LLHM tend to be larger and slower than regular hashmaps due to having to maintain a doubly linked list. Python has had one such in the standard library for a decade or so.

LHM is not slower for iteration (it's faster actually).

LHM indeed pays 2 references per node but they are well worth as it has deterministic ordering/iteration and I have witnessed numerous cases with HashMap that show up in production only due to iteration order (esp after rehashing). The code is broken but the cases did not reproduce during testing...

Now if the two extra references are an issue, consider that HashMap is quite space inefficient with having a dedicated node per each entry - that's the main price. The (simple) node memory footprint is 36bytes on heaps less than 32GB, i.e. compact pointers. The extra references add another 8 bytes for having an insert or access order.

If the goal is getting a compact low memory footprint, HashMap is not fit for purpose. Overall it's the jack of all trades and even got reworked (java8) to support tri-based collision resolution for keys that implement Comparable.

Couple years back I wrote CompactHashMap (under CC0) that has an average cost of 10bytes per entry and it's extremely compact for small sizes with having only 2 fields on its right own, so even small/empty maps are tiny. In microbenchmarks (same used in openjdk) it handily (2x) beats java.util.HashMap on "Traverse key or value", get/put have similar performance, and "Search Absent" is worse.

The point is: LHM should be the go-to hashmap for java as being node based hashmap is justified (unlike java.util.HashMap)

Re: Python dicts are now ordered

#350

Post by zeulhex »

jakear wrote: post #184
gnulinux wrote: post #142

Earlier quoted context omitted.

Why does it matter if it's explicit or not. If python doesn't support forward compatibility, you should know that if you write code for 3.7, it's not gonna work in 3.5. Doesn't seem like a big deal to me.

If you’re the only one writing it and you’re the only one running it, it’s probably fine. But if I’m putting a file out there that will only work in 3.7, it’d be nice if any potential users of that file would get a good error message if they try to run it on 3.5, rather than wrong results. I could potentially assert a version, but do I really want to do that each time I wrote something that might be used somewhere el…

Most projects use setuptools for package management, which ensures that the environment is as expected.
Post reply on HN