Standard graph API?

[Andrew Dalke]

I've been off-line for a couple months so a bit late
following up to this thread...

I too would like some standard collection of graph
algorithms, but not necessarily a standard API.  I
work with a lot of molecular graphs which means I
would prefer using names like "atoms" and "bonds"
instead of "nodes" and "edges".

David Eppstein wrote:
> I would strongly prefer not to have weights or similar attributes as 
> part of a graph API.  I would rather have the weights be a separate dict 
> or function or whatever passed to the graph algorithm.  The main reason 
> is that I might want the same algorithm to be applied to the same graph 
> with a different set of weights.

An alternative, which is both intriguing and sends alarm
bells ringing in my head is to have the algorithm
collection instead generate code as needed, so that
I can ask for, say, "depth first search using '.atoms'
to get a list of neighboring nodes."  The result could
exec'ed to generate usable Python dynamically, or
written to a file to be used as a normal Python module.

In this case if the DFS generates callback events then
it could include options to only create the code for
events that are needed.

There would need to be some standards on how the
graph is used, like "two nodes are the same iff
'node1 is node2'" or "the result of getting the list
of edges is iterable."

I believe this design philosophy is similar to Boost's.

				Andrew
				dalke at dalkescientific.com