Hacker News Reader

Comment by bouncycastle | Hacker News Reader

Fmt will print maps out in sorted order? I guess that will confuse many newcomers even more

This FOSDEM Francesc explained the rationale behind this change, and namely in order to have an easier time comparing maps while debugging.

The outputs of examples in many tutorials need to be corrected. :)

What not add a new format verb instead?

Definitely a trade-off here between being handy for people that know what's gong on and confusing for beginners...

Why should that confuse?

I think he's referring to the fact that maps are iterated in random order. Now if you print them directly, you may be lead to believe that the order is _not_ random.

Given Python's success with its insertion-order-retaining "compact dict" implementation[1], I've wondered why more languages aren't adopting that design into their maps/hashtables.

[1] https://docs.python.org/3/whatsnew/3.6.html#whatsnew36-compa...

"The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon"

Early in Go's development, they intentionally randomized the iteration offset to make sure developers didn't become dependent on a behaviour they didn't want to be tied to.

You see this in Erlang also, where iteration order is deterministic (though not based on insertion order), but documentation makes sure to say iteration is arbitrary.

So, the answer to your question is that most people don't want their dictionaries implementation to be tied down due to this feature.

> "The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon"

Except it worked so well in Python and PyPy that in Python 3.7 it was blessed into an official part of the language spec.

I wonder if this isn't going to be seen as a mistake in the future. What if a faster map is discovered in 3 years that happens to not preserve order? This stuff is really hard to detect, so there's no going back on it.

In Python, they'd probably just make it a separate class, just like `OrderedDict` is/was. People who needed the performance would use it and everyone else would enjoy the convenience of ordering.

That was likely weighed and I'm guessing the answer is that they would introduce a new type under collections, but that the new dictionary makes most sense for users while also currently being faster

> "The order-preserving aspect of this new implementation is considered an implementation detail and should not be relied upon"

FWIW https://docs.python.org/3/whatsnew/3.7.html

> the insertion-order preservation nature of dict objects has been declared to be an official part of the Python language spec.

https://mail.python.org/pipermail/python-dev/2017-December/1...

There's a big difference between "iteration order is deterministic" and "iteration order is <very specific high-level behaviour>" even if the latter is a side-effect of an implementation details. In particular, iteration order being either insertion order or sorted are useful and sought-after properties, while other implementation-dependent deterministic orderings are mostly implicit dependencies and sources of bugs (not unlike e.g. the scheduling sequence of goroutines in Go).

If you print them one by one while iterating you would quickly discover the truth. Not sure why this would be worth making the string rendering of large maps much harder to use and compare (eg in log entries). Since any rendering implies an order (which is not guaranteed to remain consistent through the program's lifetime), then any string rendering of a map should be considered misleading by your logic.

To me it's a deeper issue that this and breaches the single responsibility principle.

fmt should only print, not manipulate the data it is asked to print.

I believe that the spec says that maps iterate over keys effectively at random and so that should be the result of any operation that iterates over keys.

The `fmt` packages is described as being for "formatted i/o". It seems that ordered maps, while not "i/o" is reasonable to describe as "formatting", so it's fine to do it in this package I think.

`fmt` has always made things look prettier, that's part of what formatting is about.

You could equally argue that `fmt` should not round floats or pad numbers with zeros or spaces.

Formatting and making things prettier is not manipulation. When I call a function called "fmt.Println" is expect it to print, not sort.

As far as I can tell, it’s not manipulating, it’s formatting in sorted order.

Sorting is manipulating...

You can print in sorted order without modifying the map at all. I don’t know what definition of “manipulating” you’re using, but I struggle to imagine a definition that is both useful and consistent with your position.

The data itself is not being "manipulated", though. By definition it is unordered. You are not guaranteed that whatever order you get when iterating the keys will remain the same. But any string rendering of the map would put the keys in an "order" and thus would be "manipulating" the data according to you. Why not have the order be useful to humans?

I'm very surprised by those vitriolic comments...

Really I have never seen print change the order of the data it is given (that's manipulating, indeed) for the sake of what seems to be laziness.

If there is a real need for sorted iteration then it should be external to print, possibly a new API of maps.

How are you reading "vitriol" from these comments? "Print" isn't changing the order of the data it's given--the data is unordered by definition. It has to print it in an order, so it orders it by keys as a practical courtesy to humans. Nothing is manipulated except perhaps data structures internal to the print operation.

> "Print" isn't changing the order of the data it's given

Eh? That's exactly the functionality they are announcing...

You're missing the point entirely. Maps have no defined order. You cannot "change" the order of a map, because it has no order. `[foo:1 bar:2]` is the same map as `[bar:2 foo:1]`, there is no difference.

For printing purposes that means that it doesn't matter which order you print something out in. ANY order is equally correct. So you might as well choose the one that makes the most sense to human eyes, which is to print them out ordered alphabetically on the keys.

Just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything. Literally nothing about the map changes.

> You're missing the point entirely. Maps have no defined order. You cannot "change" the order of a map, because it has no order.

Clearly, I am not the one missing the point...

The order maps iterate is not the point. The point is that e.g. a 'print' function should print, not sort and change the order.

> just because the printing function is choosing alphabetical order to print things out in, it's not "manipulating" anything

Again, the printing function does not 'choose', it manipulates the date returned by sorting them.

My point is that, to follow good design principle, this sorted iteration should be a public API of maps.

Is rounding of a float manipulation?

It is not random, it is undeterminate. Any order follows that spec. Whether you display items in alphabetical order, in insertion order, randomly, or in any other way, you're good.

The spec relates to maps...

The point is that a print should print in the order it is getting data.

I'm confused about why this would be a problem, though. The majority of use cases I can think of for using fmt functions to render maps into strings would not be harmed in any way by presenting the map in sorted-key order. For my own use, such usage is mostly for debugging or logging purposes, in which case a sorted map is vastly preferable.

Given that the order of keys in a map is not guaranteed, I also wouldn't consider rendering them in a fixed order as "manipulation". The order of the keys is undefined, unimportant, program-wise. So presenting them in a certain order implies meaning (presumably there is one, whether it be creation order, LRU, or physical-memory layout). But if you know the keys are sorted before being printed, then you can continue to assume you don't know the actual order, or to put it another way, you can continue to suspend your disbelief about whether the keys are truly "unordered" in the system.

But to get back to practical concerns, I'm genuinely curious what harm you see from presenting the unordered keys in a predictable order that allows humans to get more use from the particular formatting?

As the other commenter noted, a lot of tutorials will probably need to be rewritten, which is what my original comment was hinting.

Reply on news.ycombinator.com