> Nice! However, what exactly should we do? I guess we're not interested
> in doing this for _all_ classes and modules, but only certain large
> ones? Should we add a keyword in the module/class docstring that
> Sphinx could pick up, indicating that the docs for this file should be
> split into man
On Dec 11, 10:56 pm, Nathann Cohen wrote:
> Hello everybody !!!
>
> My question on sphinx-dev was finally answered : it sounds possible to
> have one page per method ! :-)
>
> http://groups.google.com/group/sphinx-dev/browse_thread/thread/41a2fc...
>
> Nathann
Nice! However, what exactly should w
Hello everybody !!!
My question on sphinx-dev was finally answered : it sounds possible to
have one page per method ! :-)
http://groups.google.com/group/sphinx-dev/browse_thread/thread/41a2fc455ff98d6e?hl=en
Nathann
--
To post to this group, send an email to sage-devel@googlegroups.com
To unsu
Hi folks,
This is now ticket #10433
http://trac.sagemath.org/sage_trac/ticket/10433
I opted to move the method min_spanning_tree() from Graph to
GenericGraph. The code for Kruskal's algorithm has been moved to the
new module spanning_tree.pyx and GenericGraph.min_spanning_tree() now
calls spanni
On Dec 7, 6:56 pm, Robert Miller wrote:
> I'm not sure it is a good idea to *remove* the methods from the object
> of which they are a natural function. I've seen this argument many
> times before, and I really like this as an organizing method.
> Everything else you say seems like a good idea t
Hi Rob,
On Wed, Dec 8, 2010 at 10:49 AM, Rob Beezer wrote:
> I think it is important that a graph has hundreds of methods, since
> Sage can do hundreds of things to a graph. Tab-completion is great,
> and more robust wild-cards on tab-completion would be even better
> (isn't this one of Jason's
On 12/7/10 8:06 PM, Minh Nguyen wrote:
Hi Jason,
On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout
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
Hi Jason,
On Wed, Dec 8, 2010 at 10:26 AM, Jason Grout
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
>
Hi Nathann,
On Wed, Dec 8, 2010 at 4:22 AM, Nathann Cohen wrote:
> Would there be any way to ask Sphinx to produce one page per method
> instead of having them all on one page ?
I'm not aware of any way to get Sphinx to do what you're describing.
Essentially you want something similar to how the
I think it is important that a graph has hundreds of methods, since
Sage can do hundreds of things to a graph. Tab-completion is great,
and more robust wild-cards on tab-completion would be even better
(isn't this one of Jason's favorite suggestions?).
That said, not only is graph.py so big that
On 12/7/10 9:34 AM, Minh Nguyen wrote:
Hi Jason,
On Wed, Dec 8, 2010 at 12:15 AM, Jason Grout
wrote:
I worry that it is too confusing to have a min_spanning_tree function in the
documentation of the spanning_tree module that is different than the
min_spanning_tree method of a graph (different
I read this thread once and I will have to think about this subject
again before coming up with anything interesting. One thing though
:
Would there be any way to ask Sphinx to produce one page per method
instead of having them all on one page ? Having such a long page
containing all our metho
> Goodies like algorithms for randomized spanning tree constructions
> should go into another module like sage/graphs/trees.pyx. I feel this
> is really a time to declare a serious moratorium on adding new methods
> to any of the following modules, unless there is a good reason to do
> so:
>
> * sa
Hi Jason,
On Wed, Dec 8, 2010 at 12:15 AM, Jason Grout
wrote:
> I worry that it is too confusing to have a min_spanning_tree function in the
> documentation of the spanning_tree module that is different than the
> min_spanning_tree method of a graph (different interface, more checks,
> etc.).
Th
On 12/7/10 5:25 AM, Minh Nguyen wrote:
Hi Robert,
On Tue, Dec 7, 2010 at 9:56 PM, Robert Miller 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 (ple
15 matches
Mail list logo
