Opened 8 months ago

Last modified 7 weeks ago

#26640 new task

Meta-ticket: make graphs compatible with Python 3 — at Version 5

Reported by: dcoudert Owned by:
Priority: major Milestone: sage-pending
Component: graph theory Keywords: py3, graph
Cc: tscrim, chapoton, jhpalmieri, gh-jfraymond Merged in:
Authors: Reviewers:
Report Upstream: N/A Work issues:
Branch: Commit:
Dependencies: Stopgaps:

Description (last modified by chapoton)

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


  • #26469 avoid sorting vertex labels in
  • #26531 avoid using .vertices() in asteroidal_triples
  • #26618 avoid using .vertices() in centrality.pyx
  • #26621 avoid using .vertices() and .edges() in bliss.pyx

Needs review:

  • #26520 clean graph decompositions
  • #26633 clean (part 4)
  • #26634 clean (part 5)
  • #26663 clean (part 8) - connectivity
  • #26675 clean (part 11) - substructures
  • #26678 clean (part 12) - centrality and distances
  • #26679 clean (part 13) - searches and constructors
  • #26680 clean (part 14) - visualization

Change History (5)

comment:1 Changed 8 months ago by dcoudert

  • Description modified (diff)

comment:2 Changed 8 months ago by dcoudert

  • Description modified (diff)

comment:3 Changed 8 months ago by chapoton

  • Component changed from group theory to graph theory

comment:4 Changed 7 months ago by 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 ?

comment:5 Changed 7 months ago by chapoton

  • Description modified (diff)
Note: See TracTickets for help on using tickets.