This came up in https://trac.sagemath.org/ticket/29042 : In current IPython, dictionaries are no longer sorted on output, because in Py3 there is a slightly more meaningful order to the dict: it's close to insertion order. So it seems reasonable to follow this order for printing too. Yet, the order in not actually intrinsically meaningful for the dict. We have previously relied on the sorting of dictionaries to make doctests of dictionaries work smoothly. We need to change that if we upgrade IPython. There seem to be two main options: 1) we adjust the doctests to the new output order of IPython 2) we adjust the doctests so that the output order is somehow sorted.
The problem with 1) is that it's a nasty change (it hits quite a few doctests), and it's rather fundamentally fragile: if some code changes somewhere (or, unlikely, Py3 changes dict ordering), doctests break again. For 2) there are different possibilities. a) Something like sorted(D.iteritems()) works, but it means the doctest now displays a list of tuples rather than something that looks like a dict: not a problem for "TESTS:" but less than desirable for "EXAMPLES:". b) It looks like with `from pprint import pprint` we could just do `pprint(D)` to get a pretty-printed dict. c) we have a pretty_print(...) which could grow a `sort=True` attribute for dicts. However, its default currently is to output "latex" which is grossly inappropriate for doctests. So if we go with that, we should probably ensure that the "display manager" in force for doctests has text preference set to "plain" (and perhaps also ensure that this is the case when using the command line shell, where "latex" output is also far from pretty. Generally I'm not so in favour of making special arrangements for the benefit of doctests (just write them so that they don't rely on arbitrary peculiarities, and use "#random" if you have to display such things in the `EXAMPLES` area), but in this case we're inheriting a problem from a change in IPython, so a more systematic approach seems appropriate. Since this affects a lot of developers, a sage-devel discussion seem appropriate. Go ahead! -- You received this message because you are subscribed to the Google Groups "sage-devel" group. To unsubscribe from this group and stop receiving emails from it, send an email to sage-devel+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/sage-devel/e9427fa0-8be1-4e87-ae32-9f86b7787a34%40googlegroups.com.
