- Feature Articles
- CodeSOD
- Error'd
- Forums
-
Other Articles
- Random Article
- Other Series
- Alex's Soapbox
- Announcements
- Best of…
- Best of Email
- Best of the Sidebar
- Bring Your Own Code
- Coded Smorgasbord
- Mandatory Fun Day
- Off Topic
- Representative Line
- News Roundup
- Editor's Soapbox
- Software on the Rocks
- Souvenir Potpourri
- Sponsor Post
- Tales from the Interview
- The Daily WTF: Live
- Virtudyne
Admin
FIELD_NAME_ORDER = collections.OrderedDict({
1: 'Frist',
2: 'Snecod',
# So, a code block compatible with both Python 2 and 3? TRWTF is Python 2 being a completely different language than Python 3 and having a similar name.
})
Admin
*led
Admin
Thanks to OrderedDict and the kitchen sink approach of everything doing everything, this sort of thing is now encouraged and I'm expecting an counter blogpost about how using lists would not be extensible or something.
Admin
I wouldn't want to make any assumptions on that score. Clearly that's the case in Python 2.7 and in Java (I checked). However, in Swift (as an example), the hash is derived from the number by some algorithm, presumably in an attempt to keep an even distribution over hash table buckets in dictionaries. In fact, in Swift, the hash value isn't even guaranteed to be stable across executions of the same program.
Addendum 2021-07-26 07:58: Clarification: across different executions of the same program. It won't change while a program is executing.
Admin
The pre-3.7 dictionary implementation does not sort anything by hash (BTW the new implementation is not OrderedDict which provides additional functionality but reduced performance compared to the builtin dict implementation).
The reason the code as presented works in CPython is that with the initial dictionary capacity small integers (which hash to their integer value) drop into the corresponding hash bucket (i.e. bucket 1, bucket 2, etc). If you had integer keys larger than the initial capacity then the buckets they fall into would not be as obvious (nor necessarily be in ascending order), and once you start getting collisions then the algorithm probes, making it even less likely to have keys in order.
Admin
hashsort: https://arxiv.org/abs/cs/0408040
Admin
Code like this makes you want to order hashish.
Admin
But, but, that code makes an ordered dict from an unordered one, i.e. the order is lost anyway?
Admin
For the record, OrderedDict does still have some differences from a vanilla dictionary, including that you can actually change the order (a vanilla dict will remember insertion order, but with OD you can say "move to end"). But I would be guessing that code written like this is not ACTUALLY using those features, it's just using standard iteration order as-is.
Code like this (but with strings) is why hash randomization couldn't be enabled by default in Python 2.
Admin
Not at all different languages, and it's pretty easy to write code that's compatible with both branches. (Well, it's getting harder now, but only because you have to restrict yourself to features that existed in 2.7.) TRWTF is people still spouting that line, usually people who've never actually ported anything from Py2 to Py3.
Admin
Perhaps they thought that OrderedDict will order a dictionary based on the key values vs insertion order. There's still no out-of-the-box equivalent for C++'s [ordered_]map in Python, so you'll constantly be sorting the keys if you do a lot of in-order transversal mixed with dictionary updates. There's a 'sortedcontainers' package which seems like it fits the bill though.
Granted, it's super weird to not just use a list in this case... although with the way they did it, they have the count right next to the name, which could still be accomplished using comments.
Admin
Guilty! The reason I'm still spouting that line is that nearly every package I use requires Py2 or Py3 and won't run in the other. So apparently everyone who has ported doesn't bother to maintain compatibility. So to the end user they may as well be different languages and not pollute the command line namespace with similar names.
Admin
This sentence made me think of a Sidebar thread...
https://what.thedailywtf.com/topic/27286/the-raku-programming-language
Admin
While many people code in Python, others elect to keep anacondas as pets, in the same house with their children.
Admin
Cool that someone looked up the docs for Python. But they didn't look hard enough. https://cpython-test-docs.readthedocs.io/en/latest/library/collections.html#ordereddict-objects states "When iterating over an ordered dictionary, the items are returned in the order their keys were first added.". Also there is "Changed in version 3.5: The items, keys, and values views of OrderedDict now support reverse iteration using reversed().". If the keys and values were listed in an arbitrary order, would this note make any sense? If you do not know that the dict you are iterating over is special like OrderedDict, yes you should not make assumptions about the order. Using an OrderedDict may not be necessary, but it could be useful depending on the code written to process the CSV, which is omitted in the article.
Admin
Well, it's possible to have code that works the same in both (and I did exactly that for a few years) but now that the legs have been cut out from underneath Py2 there's really no reason to stay stuck in the past, and some of the things in Py.
Admin
Well, it's possible to have code that works the same in both (and I did exactly that for a few years) but now that the legs have been cut out from underneath Py2 there's really no reason to stay stuck in the past, and some of the things in Py.
Addendum 2021-07-27 04:41: … things in Py3 are worthwhile.
[Damnit, mishit the touchpad…]
Admin
For some reason I read that as "mis-shit the touchpad"
Admin
OrderedDict will iterate in order, yes. But the question is what order elements were added to it - it's being initialized by a plain dict which (in 2.7) does not guarantee any specific order.
Admin
Unless you are maintaining a legacy app that uses python as a scripting addon to a C++ core. In which case you are stuck.
Admin
Even in Python you can't always assume that hash(int) == int... because hash(-1) == - 2.