Hi Jason, On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout <jason-s...@creativetrax.com> wrote: > I think maybe I was too brief in my suggestion to be clear. I would favor > refactoring the code out to a spanning_tree.py(x) file. My point was that > your propositions seemed to indicate that the graph class methods that would > call spanning_tree.min_spanning_tree would also do some additional error > checking, maybe have a different interface, etc. My suggestion was to not > have any additional code; put all of that error checking, etc., into the > spanning_tree.min_spanning_tree function. In other words, the graph class > would simply import the functions into the class namespace: > > class Graph: > from spanning_tree import min_spanning_tree > > That way we get a standalone function in spanning_tree.min_spanning_tree, > and we also get a convenient method for all graphs, and they are exactly the > same function, have the same interface, etc. There is no duplication of > code or of doctests. > > Of course, this import should probably be moved up to the generic graph > class, like you suggest, if the function can handle digraphs too.
The above seems very reasonable to me. Documentation for spanning trees would be advertised on the top-level page for graph theory, while we refactor spanning tree code into the proposed module spanning_tree.py(x) and import min_spanning_tree() somewhere in generic_graph.py. This means that one could still discover min_spanning_tree() via tab completion (using a graph object) and also have the code for min_spanning_tree() centralized somewhere. -- Regards Minh Van Nguyen -- To post to this group, send an email to sage-devel@googlegroups.com To unsubscribe from this group, send an email to sage-devel+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/sage-devel URL: http://www.sagemath.org
