methods using matrices: adjacency_matrix, distance_matrix, etc. For all these methods, we can now give as input an ordering of the vertices (and edges) that will be used to order rows and columns. Currently, we use .vertices() and .edges() by default. If we switch to list(G) by default, we have to check that it's not breaking algorithms using these matrices.

I'm answering here the question of ​#26567#comment:9 about how to make iterator_edges of sparse_graph.pyx py3 compatible, and if something similar to #26567 for dense_graph.pyx can be done for sparse_graph.pyx.

So far, I don't know what's the best option.

just stop ordering end vertices of edges as well as vertices in general, but it shall break many algorithms

change the way we use graphs to ensure that internally vertices are all integers, and then use method get_vertex_label (that we already have but rarely use) only when the user wants to display lists of vertices/edges. I think networkx is now doing something like that.

try to mimic the py2 sorting using try... except statements, but this might induce some slowdown.

maintain an ordering of the vertices and a mapping from vertices to integers used when sorting list of vertices and the end vertices of edges. This ordering could be updated at vertex insertion/deletion time.

All these options have pros and cons, and each of them will require a significant amount of work to fix doctests and algorithms.

In the last months, we did significant progresses on reducing the dependency on ordering, but this is not enough and this central issue is very complex to fix. Which is the best option in the short/long term ?

I'm not good enough with git to know what you have changed, except the first 2 calls to .vertices(). It seems ok. Note that the function has 2 more calls to .vertices() that are clearly useless. I think the proposed change fix some doctests, so you should open a ticket.

Retarging tickets optimistically to the next milestone. If you are responsible for this ticket (either its reporter or owner) and don't believe you are likely to complete this ticket before the next release (8.7) please retarget this ticket's milestone to sage-pending or sage-wishlist.

I would like to ask some questions about how to deal with simplicial complexes.

The is_isomorphic method for simplicial complexes translates each complex to a graph and then asks whether they are isomorphic, preserving edge labels. Some edges are labeled and some are not: the edge labels look like

sage: g.edge_labels()
[None,
None,
'special_edge',
'special_edge']

This fails in Python 3 because it tries to sort edges, and it can't sort str and NoneType. It is easy enough to provide labels in this case, but should the graph is_isomorphic method deal well with graphs where some edges have labels and some don't? (I don't have an opinion and I will fix the simplicial complex code separately.)

Again with the is_isomorphic method for simplicial complexes: it defines a graph with vertices labeled by the vertices of the complex and its facets, and it adds an edge between a vertex v and a facet f if v is in f. The graph code tries to sort the vertices, and since the vertices in a simplicial complex can be integers, strings, whatever, the sorting goes badly. Again, I think I can handle this for simplicial complexes by translating everything to something sortable, then sorting, and then translating back at the end, but should the graph is_isomorphic method handle these sorts of cases better?

Once again, I could probably get around this by translating all of the vertices to something sortable and then translating back, but I do think that the graph theory code should be able to handle graphs whose vertices are a combination of int and str and anything else. I would like to put in a request for fixing this particular problem.

I fully agree that the graph theory code should be able to handle vertices of different types. We have done significant progresses recently, and many methods are no longer sorting vertices. But a lot remains to be done since a huge part of the code uses vertex ids instead of internal int labels. We have to find solutions for instance for listing edges as end points are currently sorted...

Note that I'm not able to try your example with py3 as this S1.wedge(S1).graph() already raises an error.

First, you have all done great work with graphs, and you've made a tremendous amount of progress. Partly my questions were because I don't know whether some of these things have been done in tickets which have not yet been merged, but I think that's not the case.

Speaking of things which have not yet been merged, you need #26966 to be able to do S1.wedge(S1).graph(). Sorry, I hadn't realized that when I posted my example.

Also, as I hope was clear in my questions, the first two are not critiques but honest questions: I don't know how Sage should handle those situations. The fact that things happen to work in Python 2 does not mean that they should automatically work in Python 3. For example, if you explicitly ask for isomorphisms preserving edge labels, an argument could be made that you should actually label all of the edges. The last item on my list was an explicit request, which it sounds like you agree with but also sounds like it take some work.

methods using matrices: adjacency_matrix, distance_matrix, etc. For all these methods, we can now give as input an ordering of the vertices that will be used to order rows and columns. Currently, we use .vertices() by default. If we switch to list(G) by default, we have to check that it's not breaking algorithms using these matrices.

methods using .relabel(). We must check that changing the default ordering of vertices/edges is safe. Should be ok, but we never know...

methods for isomorphisms were we also have issues with labels (see e.g. #27232 although the case is certainly beyond what we should reasonably do).

Deprecate sorting of vertex labels in method iterator_edges of base/sparse_graph.pyx (so of the vertices of an edge). Deprecating this behavior is certainly a hard task. A first step could be to order the vertices according internal integer value, thus ensuring that (u, v) will always be ordered the same way.

And of course, changes done here will certainly break many methods in other modules...

The branch at #27452 relabels the graph of a simplicial complex so that the vertices are sortable, before trying to compute its minimal spanning tree. Is this just sweeping things under the rug, or is it okay?

I think it is one way forward. It does suffer in large cases because you have to make a full copy of the simplicial complex's graph, but I don't think it is simply sweeping it under the rug. Perhaps for that a user should know better than to have complicated labels for such tests?

An alternative is to (optionally) make spanning tree methods return a Graph, in which case there is no need to sort end vertices.

My gut reaction was that seems heavy handed. It would make sense, but I suspect the reason we don't is because it would be too expensive (relatively) to return a (Di)Graph. I haven't looked into this (it is too late for me to do so tonight), but just a thought.

For this one, I would be tempted to label it # py2 since it seems to rely on the legacy Sage notebook. I can open a ticket if that sounds like a valid approach.

It is related to sage notebook, but doctests are failing only with py3... So I don't know which is the best approach. Should we try to make a little change to sagenb to make #27435 fixing the issue, although sagenb will be removed in the future (but when?) ?