Hi Robert, On Tue, Dec 7, 2010 at 9:56 PM, Robert Miller <r...@rlmiller.org> wrote: > I think you can accomplish all these goals without "unbloating" > graphs.
Of course it can be done without unbloating the various graph classes. > I think Sage users have gotten used to (please feel free to > correct me on this, Sage users!) looking for a method via tab > completion. Here are two ways to refactor code, while keeping users happy. Both approaches below rely on keeping the current interfaces for spanning tree methods, while also creating a new module called sage/graphs/spanning_tree.py(x). * Move the relevant core code to the said proposed module. The core code I'm referring to would be code that does the actual computation of spanning trees, excluding some basic sanity checks, etc. The relevant existing methods would be rewritten to call the corresponding interfaces in sage/graphs/spanning_tree.py(x). Take the case of min_spanning_tree() in sage/graphs/graph.py. We move the core code that computes minimum spanning trees into sage/graphs/spanning_tree.py(x) and improve the minimum spanning tree code in that new module. The method min_spanning_tree() would not be removed entirely, but would still retain its current interface and have some possible improvement as necessary. It's only the definition that would be changed; the rewritten definition would actually call the relevant minimum spanning tree function in sage/graphs/spanning_tree.py(x) to do the heavy duty work of computing minimum spanning trees. Furthermore, we add a new method called min_spanning_tree() to the class definition of digraphs in sage/graphs/digraph.py to mirror its counterpart in sage/graphs/graph.py. But we actually call the relevant function in sage/graphs/spanning_tree.py(x) as per the rewritten min_spanning_tree() for undirected graphs. * Do the same as in the previous approach, but add deprecation warnings to the effect that the relevant methods would be entirely removed in a future release. In both of the above approaches, code for spanning trees would be centralized in sage/graphs/spanning_tree.py(x) and hence could be advertised more clearly in the reference manual. > I worry about how many features we have for graphs already > which I have seen users surprised to find. Follow Guido van Rossum's precedent by declaring a moratorium on adding further methods to the class definitions of undirected and directed graphs :-) > Cleaning up documentation > might make more people more aware of what Sage can do, but I think > moving these methods (at least in name) out of the graph classes would > be a push in the other direction. See my new proposal above. -- 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