[Python-ideas] Graph class
Terry Reedy
tjreedy at udel.edu
Tue Dec 18 17:06:29 CET 2012
On 12/18/2012 9:24 AM, Yuval Greenfield wrote:
>
> On Tue, Dec 18, 2012 at 2:08 PM, Oscar Benjamin
> <oscar.j.benjamin at gmail.com
> <mailto:oscar.j.benjamin at gmail.com>> wrote:
> I'd be interested to use (and possibly to contribute to) a graph
> library of this type on PyPI. I have some suggestions about the
> appropriate level of abstraction below.
>
> The graph algorithms that are the most useful can be written in terms
> of two things:
> 1) An iterator over the nodes
Or iterable if re-iteration is needed.
> 2) A way to map each node into an iterator over its children (or
> partners)
A callable could be either an iterator class or a generator function.
> Some graphs don't care for the nodes, all their information is in the
> edges. That's why most graph frameworks have iter_edges and iter_nodes
> functions. I'm not sure what's the clean way to represent the
> optional directionality of edges though.
>
> Some example API's from networkx:
>
> http://networkx.lanl.gov/reference/classes.html
> http://networkx.lanl.gov/reference/classes.digraph.html
Thank you both the the 'thought food'. Defining things in terms of
iterables and iterators instead of (for instance) sets is certainly the
Python3 way.
Oscar, I don't consider hashability an issue. General class instances
are hashable by default. One can even consider such instances as
hashable facades for unhashable dicts. Giving each instance a list
attribute does the same for lists.
The more important question, it seems to me, is whether to represent
nodes by counts and let the algorithm do its bookkeeping in private
structures, or to represent them by externally defined instances that
the algorithm mutates.
--
Terry Jan Reedy
More information about the Python-ideas
mailing list