Closed pcostell closed 9 years ago
Issue #5 is about this, more or less.
It's unlikely I'll find the time to work on it any time soon, and I'm not very confident in my API design skills.
FWIW
This results in some weird cases where to show a set of chains, find_chain is called to collect all nodes that are involved in the chain, then show_graph calculates all chains again and just uses the already built chains as a filter
We need to calculate the chain again if we want to represent it, since edge labels are computed on the fly (e.g. if a dictionary X refers to an object Y, we need to iterate over X.items() in order to find the key K where X[K] is Y). The way culling is implemented in show_chain should mean that _show_graph doesn't traverse unnecessary nodes.
We could eliminate the need to do a double traverse if we store edge labels in a data structure while we're traversing the graph in find_chain. We'd need to store those somewhere. Maybe we could have a Graph object that represents the nodes and edges that ought to be drawn.
Yes I was thinking something Graph object like. I'll close in favor of keeping the discussion on issue #5.
Right now there are multiple places that have very similar functionality. For example
show_graph
andfind_chain
both search for a chain from the supplied object to a predicate (infind_chain
the predicate is user specified, inshow_graph
it is a module). This results in some weird cases where to show a set of chains,find_chain
is called to collect all nodes that are involved in the chain, thenshow_graph
calculates all chains again and just uses the already built chains as a filter.Instead I imagine this could be consolidated into something more like:
find_graph(...) and find_graph(..., shortest_path=True) where the logic is more or less the same but shortest_path just has an early end condition. Then
find_chain
is obsoleted by find_graph(..., shortest_path=True) andshow_chain
is obsoleted byshow_graph
which only has to contain the logic for creating the DOT format.