Meta-ticket: make graphs compatible with Python 3

[dcoudert]

This ticket is used to keep track of the progress towards python3 in graphs.

Major issues

• methods .vertices() and .edges() use sort by default
• direct comparison of vertex labels (e.g., in method iterator_edges of base/sparse_graph.pyx)
• all min_spanning_tree methods sort edges before returning the result - #26940 is attempt to stop sorting returned list of edges

Needs work:

• #26800 py3: bug with canonical_label

Needs review:

• #26520 Meta-ticket for methods in src/sage/graphs/graph_decomposition/ - #26827, #26828, #26829, #26830, #26831, #26832, #26833, #26834
• #26678 clean generic_graph.py (part 12) - meta-ticket for methods related to clustering, centrality and distances. Tickets are #26803, #26813, #26814, #26815, #26819, #26820, #26821, #26822, #26823, #26824, #26825, #26826
• #26679 clean generic_graph.py (part 13) - searches and constructors
• #26940 stop sorting returned list of edges in spanning tree methods
• #26971 py3: some minor fix for traveling salesman

Done

• #26274 avoid comparison of vertex labels in MIP - graph_coloring.py
• #26282 avoid comparison of vertex labels in MIP - graph.py
• #26284 avoid comparison of vertex labels in MIP - connectivity.pyx
• #26285 avoid comparison of vertex labels in MIP - generic_graph.py
• #26469 avoid sorting vertex labels in graph_plot.py
• #26478 clean graph_plot_js.py, graph_list.py and graph_input.py
• #26480 clean graph_latex.py
• #26484 clean graph_coloring.py and avoid comparison of vertex labels
• #26528 avoid using .vertices() in comparability, hyperbolicity and distances_all_pairs
• #26531 avoid using .vertices() in asteroidal_triples
• #26534 avoid using .vertices() in weakly_chordal.pyx
• #26554 improve the boost graph interface to avoid using .vertices()
• #26618 avoid using .vertices() in centrality.pyx
• #26621 avoid using .vertices() and .edges() in bliss.pyx
• #26622 avoid using .vertices() in convexity_properties.pyx
• #26624 clean generic_graph.py (part 1)
• #26627 clean generic_graph.py (part 2)
• #26630 clean generic_graph.py (part 3)
• #26633 clean generic_graph.py (part 4)
• #26634 clean generic_graph.py (part 5)
• #26637 clean generic_graph.py (part 6)
• #26658 clean generic_graph.py (part 7) - planarity
• #26663 clean generic_graph.py (part 8) - connectivity
• #26666 clean generic_graph.py (part 9) - edge and vertex handlers
• #26672 clean generic_graph.py (part 10) - degree
• #26675 clean generic_graph.py (part 11) - substructures
• #26680 clean generic_graph.py (part 14) - visualization
• #26711 avoid .vertices() in graph_coloring.py
• #26712 avoid .vertices() in independent_sets.pyx
• #26757 py3: fixing round in graph_latex.py
• #26761 py3: fix BlanusaSecondSnarkGraph
• #26762 py3: fix HortonGraph generator
• #26763 py3: fix SzekeresSnarkGraph generator
• #26779 py3: fix graph_input.py and hypergraph_generators.py
• #26801 py3: change sorting of neighbors labels in static_sparse_graph.pyx
• #26812 py3: fix doctest in graph_generators.py
• #26846 for graph isomorphism
• #26851 py3: avoid .vertices() and .edges() in union of graphs
• #26869 py3: improve is_aperiodic to fix doctests (due to deprecation warning in networkx)
• #26870 py3: fix error with map in strongly_regular_db.pyx
• #26871 py3: fix doctests in digraph_generators.py

[dcoudert]

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 ?

[chapoton]

May I ask in which ticket, if any, you do touch the "is_isomorphic" method ?

I would really like this to work with python 3:

sage: G = Graph()
sage: G.add_edge((1,'a'))
sage: G
Graph on 2 vertices
sage: G.is_isomorphic(G)

[dcoudert]

I have not touched any method related to isomorphism. I have only opened a ticket to show a bug with canonical_label #26800.

[chapoton]

ok.. Then either we wait for all these tickets to be closed (and this may take a lot of time) or we can try to fix this isomorphism problem now..

[dcoudert]

We can start working on it. In the worst case, I will have to fix some merge conflicts.

[chapoton]

I have made a first tentative at u/chapoton/graphe_iso

[dcoudert]

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.

[chapoton]

I made #26846 for graph isomorphism

[chapoton]

Salut !

• we should probably add #26971 somewhere

• where are the plot methods handled ?

[dcoudert]

See #26469, #26478, #26480, #26484.

I will check #26971 soon.