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

411–420 of 457 posts

Re: Python dicts are now ordered

#411

Post by jillesvangurp »

Java has many types of Map, Set, and List implementations. And that's just in the core library. Here are some Map implementations that come with Java: TreeMap, a HashMap, A LinkedHashMap, ConcurrentHashMap, EnumMap. There are many more and they each have their own uses, features, and performance/memory characteristics.

I always wondered why languages like ruby, javascript, and python don't include a bit more choice on this front. It seems like sets are still somewhat of a novelty for javascript developers and people just wing it with half-assed solutions involving stupid O(N) contains operations.

Re: Python dicts are now ordered

#412

Post by njharman »

biddlesby wrote: post #26
setr wrote: post #20

Earlier quoted context omitted.

I'm not clear on how this break existing code. Code that assumed it was arbitrary, would expect to handle any arbitrary order, including a happens-to-be sorted order. Code that assumed it was random, like actually inserted by random(), was already broken, because that simply isn't the case. Code that assumed the order would stay constant was relying on implementation-specific behavior, and could potentially break on…

It doesn’t break existing code. Code written for Python 3.7 might break on older versions of Python

> Code written for Python 3.7 might break on older versions of Python

That's a truism. For all versions of Python. If you use feature of python ver X, you should not be surprised that it doesn't run on versions less than X that lack that feature!!!

If you write a Python library and use feature of Python ver X and don't mark library as only >= Python ver X, you are doing it wrong and a horrible person.

Re: Python dicts are now ordered

#413

Post by jrwr »

zeroimpl wrote: post #387
mattkrause wrote: post #333

Earlier quoted context omitted.

In that situation, Matlab allocates an array of length 3, fills it with “empty” values (depending on the type), and then sets the third element to the value. That’s what I’d have expected to happen here too...

Would you expect it to do that if somebody wrote the following? $id = 12835151; $arr[$id] = Get_thing_with_id( $id );

In my bog standard PHP I would do $thing = Get_thing_with_id( $id ); if(!empty($thing)){process($thing);}

Re: Python dicts are now ordered

#414

Post by deniska »

fyp wrote: post #325
reidrac wrote: post #257

Earlier quoted context omitted.

The title of the post is misleading: it means "ordered by insertion order" (not sorted). Previously it was unpredictable, and that's why collections have OrderedDict; which makes sense instead of trusting an implementation detail of CPython from 3.6. Is not mentioned in the docs: https://docs.python.org/3/library/stdtypes.html#mapping-type... EDIT: but the behaviour is documented in OrderedDict itself! https://docs.p…

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.

Re: Python dicts are now ordered

#415

Post by wodenokoto »

jkbbwr wrote: post #15

Am I the only one that thinks this is a stupid decision? This will silently break code that starts to rely on this behaviour that gets executed on Python3.5 and lower. I would consider changing how a builtin works to be a major breaking change. It would have been fine if this was a change between 2 and 3 but on a minor version? Thats insane.

I think you bring up a good point. If someone hands me a python script and told me it was 3.7 I would only hear 3 and expect it to run or fail, not to run with differing outputs!

Dot-upgrades do allow for breaking changes, but this one can break silently and I’m not sure where such breakages neither belongs in python nor where they should belong.

Personally I’m happy to get ordered ducts sooner rather than later.

Re: Python dicts are now ordered

#416

Post by Aachen »

orf wrote: post #366
jakear wrote: post #184

Earlier quoted context omitted.

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…

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 your ~/bin or whatever you fancy (that's your personal preference anyway unless I'd specifically package it for some OS like Debian). I don't want to have to use some setup.py that I have no clue where in my OS it installs things.

Re: Python dicts are now ordered

#417

Post by rbobby »

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…

JavaScript is a small, reasonably elegant scripting language consisting entirely of edge cases.

/s

Re: Python dicts are now ordered

#418

Post by zo1 »

philwelch wrote: post #354
jwkane wrote: post #326

Earlier quoted context omitted.

It's significant to a human that wants to know what has changed.

If a human is inspecting serialized JSON using pen and paper, the human is presumably clever enough to match up key for key regardless of ordering. If the human is using a computer to compare two JSON payloads (as the use of a diffing algorithm suggests), the human and computer should be clever enough as a team to realize that they could just deserialize and reserialize each JSON payload such that the keys were lexic…

Most diff programs don't have what you describe. And in a lot of cases you don't have the easy ability to "do stuff" before running the input through a diffing algorithm.

Re: Python dicts are now ordered

#419

Post by zo1 »

dehrmann wrote: post #79

I've written a lot of Python, but more Java. This is where I have a gripe with "batteries included." In Java, I'd have to think slightly about this, then use a LinkedHashMap. It's been in Java since *2002. It also has a Set flavor. Python just doesn't have as rich of a collection of included data structures, and the APIs are more limited.

You call that a failing, and others call that a feature. I love the fact that I haven't had to think about ridiculous nit-pick level data-structure trade offs. In python you have a very basic set of data structures, and short of doing something ridiculously novel or exotic, that's all you need. It's part of the beauty of the language.

Re: Python dicts are now ordered

#420

Post by ben509 »

tene wrote: post #298
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…

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…

Very few algorithms really care, rather, it's when you're composing them that maintaining insertion order avoids a lot of boilerplate in having to cart that information around.

For the same reason, though, it's potentially a bad idea. All these algorithms that generate dicts generally won't promise to maintain insertion order, they just happen to by chance. Then consumers come to depend on it and be surprised when it inevitably changes.

Post reply on HN