On Fri, Dec 7, 2012 at 4:22 PM, Thomas Kluyver <<a href="mailto:thomas@kluyver.me.uk">thomas@kluyver.me.uk</a>> wrote:<br>> On 7 December 2012 21:45, Mark Adam <<a href="mailto:dreamingforward@gmail.com">dreamingforward@gmail.com</a>> wrote:<br>
>><br>>> I have a decent semi-recursive Graph class that I think could be a<br>>> good addition to the Collections module.  It probably needs some<br>>> refactoring, but I'm posting here to see if there's any interest.<br>
><br>> For reference, there was a previous idea to make some kind of standard Graph<br>> API:<br>> <a href="http://wiki.python.org/moin/PythonGraphApi">http://wiki.python.org/moin/PythonGraphApi</a><br><br>All very interesting.  I'm going to suggest a sort of "meta-discussion" about why -- despite the power of graphs as a data structure -- such a feature has not stabilized into a workable solution for inclusion in a high-level language like Python.<br>
<br>I identity the following points of "wavery":<br><br>1) the naming of methods (add_edge, vs add(1,2)):  <b>aesthetic grounds,</b><br>2) what methods to include (degree + neighbors or the standard dict's __len__ + __getitem__):  <b>API grounds</b><br>
3) how much flexibility to be offered (directed, multi-graphs, edge weights with arbitrary labeling, etc.):  <b>functionality grounds</b><br>3) what underlying data structure to use (sparse adjacency dicts, matrices, etc):  <b>representation conflicts</b>.<br>
<br>And upon further thought, it looks like only a killer application could ever settle the issue(s) to make it part of the standard library.<br><br>mark