Finite Family: sort dictionary keys in repr

[embray]

Although the order of indices is not necessarily meaningful, it often makes for nicer, more human-meaningful output to sort them. For example:

sage: A = Algebras(QQ).WithBasis().Filtered().example()
sage: grA = A.graded_algebra()
sage: grA.algebra_generators()
Finite family {'x': bar(U['x']), 'y': bar(U['y']), 'z': bar(U['z'])

instead of the more seemingly arbitrary

Finite family {'y': bar(U['y']), 'x': bar(U['x']), 'z': bar(U['z'])

which of course is itself a result that is not in any way guaranteed.

In addition to being more user-friendly, this change will also help a lot with tests that otherwise fail on Python 3 due to arbitrary differences in dict key ordering.

[git]

Branch pushed to git repo; I updated commit sha1. New commits:

​05b00ee	Fix the FiniteFamily repr to sort its defining dictionary.
​cf4855e	Tests whose expected output needs to be updated now that FiniteFamily's

[tscrim]

I had meant to respond to this earlier, but it fell off my radar.

I think that FiniteFamily should print out following self._keys if that is not None (which also dictates iteration order) and then fallback to the sorted output (see the values method).

[embray]

I see, that makes sense.

[embray]

Ah, I knew I already did this, and forgot it still needed work :) I was just about to do it again...

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​5cea4bb	Fix the FiniteFamily repr to sort its defining dictionary.
​87c7339	Tests whose expected output needs to be updated now that FiniteFamily's
​86aaf43	Change the repr formatting to ensure that if the keys argment was given,

[embray]

Hold on, just realized this is actually wrong

[git]

Branch pushed to git repo; I updated commit sha1. This was a forced push. New commits:

​4573574

Change the repr formatting to ensure that if the keys argment was given,

[tscrim]

What if the keys are not sortable, say 'a' and 1 (in Python3)? I think the sorting order needs to be in a try-except block and just default to some ordering if sorted fails.

[tscrim]

I think this will fail with your branch:

sage: sorted([complex(1), complex(2)])
---------------------------------------------------------------------------
TypeError                                 Traceback (most recent call last)
<ipython-input-7-6dddb83c526f> in <module>()
----> 1 sorted([complex(Integer(1)), complex(Integer(2))])

TypeError: no ordering relation is defined for complex numbers
sage: L = [complex(1), complex(2)]
sage: Family(L, lambda x: x)
Finite family {(1+0j): (1+0j), (2+0j): (2+0j)}

(I am at the airport waiting for a flight and my laptop only have 8.3.beta0, so I cannot test it right now.)

[embray]

True--I didn't see any cases in the tests where that was a problem but that could certainly happen I guess. On Python 3 pprint uses a "safe key" wrapper for the keys which falls back to Python 2-style ordering for unorderable types.

I mentioned in my commit message that we might want to add something like this to Sage--I've definitely been finding other places in Sage where one would like to at least order things as best possible. Maybe I'll go ahead and do that first...

[embray]

Still planning to work on fixing this up. I'm running into issues with these again :)

[embray]

I believe this issue can reasonably be addressed for Sage 8.4.

[tscrim]

Any progress?

[chapoton]

ticket was duplicated in #26225...

[chapoton]

let us close this one as duplicate

[embray]

Ok.