[Python-ideas] Fwd: Graph class

[Stephen J. Turnbull]

Mark Adam writes:

 > graph).  But imagine if, for example, Subversion used a python graph
 > class to track all branches and nodes in it's distributed revision
 > control system.  Then how easy it would be for third parties to make
 > tools to view repos or other developers to come in and work with the
 > dev team:  they're already familiar with the standard graph class
 > structure.

This is a fallacy.  As has been pointed out, there is a variety of
graphs, a large variety of computations to be done on and in them, and
a huge variety in algorithms for dealing with those varied tasks.  For
a "standard" graph class to be useful enough to become the OOWTDI, it
would need to deal with a large fraction of those aspects of graph
theory.

Even so, people would only really internalize the parts they need for
the present task, forgetting or (worse) misremembering functionality
that doesn't work for them right now.  Corner cases would force many
tasks to be done outside of the standard class.  Differences in taste
would surely result in a large number of API variants to reflect
users' preferred syntaxes for representing graphs, and so on.  I think
making a "Graph" class that has a chance of becoming the OOWTDI is a
big task.  Not as big as SciPy, say, but then, SciPy isn't being
proposed for stdlib inclusion, either.

As usual for stdlib additions, I think this discussion would best be
advanced not by "going all meta", but rather by proposing specific
packages (either already available, perhaps on PyPI, or new ones --
but with actual code) for inclusion.  The "meta" discussion should be
conducted with specific reference to the advantages or shortcomings of
those specific packages.  N.B. A reasonably comprehensive package that
has seen significant real-world use, and preferably has a primary
distribution point of PyPI, would be the shortest path to inclusion.