This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author dam1784
Recipients dam1784, eric.smith, python-dev, rhettinger, tim.peters
Date 2022-01-21.00:26:51
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <1642724811.82.0.109132459247.issue46071@roundup.psfhosted.org>
In-reply-to
Content
> If the way the user collects their data stores only successor links (which, as above, seems odd in applications that actually use topsorts), then they need something like this instead:

Actually they only need to do this:

ts = TopologicalSorter(my_forward_graph).static_order()
ts = reversed(ts)


I think part of the issue here is that the document uses two terms to describe the same thing: "predecessor" and "edge-direction". Everywhere it discusses predecessors it gets it right, but the edge direction is hopelessly confused because they tried to use the "normal" definition of topo-sort and the only way to make that work is to also reverse the direction of the graph's edges to compensate (and the two reversals cancel each other out).

The edge direction is only mentioned twice in the whole document, once to define topo-sort and again to define the graph format.

If the users problem fits into the task dependency paradigm, then this library makes a lot of sense. But for users who just have a directed graph, the documentation is really really confusing. 

I think it would be much better if the document explained that this was a "reversed" topological sort with a slightly different definition, and used a "bog standard" graph format like for example in this tutorial: https://www.python.org/doc/essays/graphs/
History
Date User Action Args
2022-01-21 00:26:51dam1784setrecipients: + dam1784, tim.peters, rhettinger, eric.smith, python-dev
2022-01-21 00:26:51dam1784setmessageid: <1642724811.82.0.109132459247.issue46071@roundup.psfhosted.org>
2022-01-21 00:26:51dam1784linkissue46071 messages
2022-01-21 00:26:51dam1784create