Python dicts are now ordered • Hacker News Board

Re: Python dicts are now ordered

#421

Post by orf » Sat, Feb 08, 2020, 12:27 PM UTC

Aachen wrote: post #416

orf wrote: post #366

Earlier quoted context omitted.

Setuptools solves this, add a python version specifier to your setup.py or pyproject.toml file. If you are just distributing raw python files then congratulations you’ve just realised why packaging is valuable.

If I rely on a python version and I expect other people to use it, I add a version if statement on top. I hate those packaging tools that insist on installing stuff in your system and create a frankendebian when really all I want to do is run a single py file standalone once. Often have to do chenanigans like "python3 -c 'from sometool import __app__'". If you want to install it, go ahead and copy or symlink it in yo…

Yes, a failure to understand how your tools work or how to use them effectively does indeed make things harder.

Re: Python dicts are now ordered

#422

Post by travisjungroth » Sat, Feb 08, 2020, 12:56 PM UTC

deniska wrote: post #414

fyp wrote: post #325

Earlier quoted context omitted.

I wonder why OrderedDict isn't outright deprecated (or reimplemented as a trivial wrapper over dict). You can get the first/last key of a 3.8 dict with dict.keys() and reversed(dict.keys()) which you can then delete to reimplement OrderedDict.popitem. Deleting a key and reinserting it will let you reimplement move_to_end. The only cool thing that OrderedDict's implementation might be useful for is to move to front (o…

When OrderedDict is compared with another OrderedDict, it also checks whether the order of items is the same (this way also violating LSP, but that's another story), dict instances don't do that.

Thanks, I just learned something.

Re: Python dicts are now ordered

#423

Post by fctorial » Sat, Feb 08, 2020, 1:04 PM UTC

gruez wrote: post #400

fctorial wrote: post #382

Earlier quoted context omitted.

#!/usr/bin/env python3.7

so now you have to install a specific python version for your script to work?

Only if you're using version specific features.

Re: Python dicts are now ordered

#424

Post by cocoa19 » Sat, Feb 08, 2020, 1:20 PM UTC

Unpopular opinion: I'd rather have classes that have precise meanings such as in Java. ArrayList, HashMap, TreeMap.

Having classes with ambiguous names makes it seem like a toy language.

Re: Python dicts are now ordered

#425

Post by crashbunny » Sat, Feb 08, 2020, 1:35 PM UTC

dr_zoidberg wrote: post #373

BiteCode_dev wrote: post #266

Earlier quoted context omitted.

First, cPython is 99% of Python deployments. So much that if a script works on it but not on another implementation, people often consider the later broken. As this post proves that most people don't even know about this feature, you can be pretty sure the vast majority of people don't know about pypy, micropython, etc. Secondly, even if you want to nit pick, Python 3.7 made it official more than one year ago. We are…

There's a great talk by David Beazley[0], which I don't remember its title right now, where he bashes all previous python versions except the latest at the time[1], which was 3.6. And he says "since I'm not a core developer, I can tell you this: rely on dicts being ordered so much that eventually they'll make it official". Guess he "won" in the end ;) [0] Well, he usually gives great talks anyway [1] Alright, he lite…

Raymond Hettinger does or did a few talks on dictionaries too. He covers the history of dictionaries in python and how they evolved. It was mentioned in the article's comment section.

https://www.youtube.com/watch?v=p33CVV29OG8

Re: Python dicts are now ordered

#426

Post by jeen02 » Sat, Feb 08, 2020, 1:45 PM UTC

BiteCode_dev wrote: post #266

rplnt wrote: post #251

Earlier quoted context omitted.

> about a feature we had since Python 3.6, in 2016 No, you had that feature in one implementation. Now it's in the language specification. That's vastly different because only now you can rely on it without fearing it can go away with the next release.

First, cPython is 99% of Python deployments. So much that if a script works on it but not on another implementation, people often consider the later broken. As this post proves that most people don't even know about this feature, you can be pretty sure the vast majority of people don't know about pypy, micropython, etc. Secondly, even if you want to nit pick, Python 3.7 made it official more than one year ago. We are…

Whoa, calm your horses angry boy.

Re: Python dicts are now ordered

#427

Post by [deleted] » Sat, Feb 08, 2020, 2:23 PM UTC

[deleted]

Re: Python dicts are now ordered

#428

Post by [deleted] » Sat, Feb 08, 2020, 2:36 PM UTC

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…

[deleted]

Re: Python dicts are now ordered

#429

Post by yason » Sat, Feb 08, 2020, 2:40 PM UTC

Funny, I've never expected or needed dict to be ordered. I've known about collections.OrderedDict but never really found much use for it. A dictionary is a hashtable and the order generally isn't important for typical uses of a hashtable. So, what is it that people are putting in dicts where the order of insertion actually matters?

Re: Python dicts are now ordered

#430

Post by dTal » Sat, Feb 08, 2020, 3:34 PM UTC

mehrdadn wrote: post #308

tene wrote: post #298

Earlier quoted context omitted.

Could you explain some examples of what this is useful for? What sort of algorithms or operations do you have in mind where you both want insertion order, and also key-based lookup in the same data structure? I've made heavy use of all kinds of maps, and of queues and channels and arrays, but I don't recall ever noticing a situation where I wanted the properties of both mixed into the same data structure. I'd love to…

For "algorithms", I mean, some really do care about insertion order. Like idk, if you have a priority queue, then you generally want FIFO ordering when the priority is the same? It like a pretty obvious desire in most cases... imagine a thread scheduler or a packet scheduler or what have you. But generally it's about determinism and avoiding loss of information, not just whether a particular algorithm needs it. For e…

If --w can be specified in two places for "an entirely different reason", then an unordered data structure is simply inappropriate, full stop. That's not a question of debugging, that's a question of correctness.