#18926: Auto-generated index of functions
-------------------------+-------------------------------------------------
Reporter: | Owner:
ncohen | Status: needs_info
Type: | Milestone: sage-6.8
enhancement | Resolution:
Priority: major | Merged in:
Component: | Reviewers:
documentation | Work issues:
Keywords: | Commit:
Authors: | e1a3241375269c7f8bff7431e5bceee79f094641
Nathann Cohen | Stopgaps:
Report Upstream: N/A |
Branch: |
public/18926 |
Dependencies: |
-------------------------+-------------------------------------------------
Comment (by ncohen):
Hellooooooooooo !
> Clever idea and nice code. I like it.
Thanks. I like it too `:-P`
> * The doc string doesn't specify that you can give the function a module
(only a class).
Sorry. Fixed.
> * You could add a doc-test that passing a class or module also works.
For good
> quine humour, it could be:
>
> sage: gen_rest_table_index(sage.misc.rest_index_of_methods)
> ....
Good idea, done.
> * What exactly do you filter out with the `inspect.getmodule(root) ==
inspect.getmodule(f)` check?
The imported modules. If you remove it, you will see
`gen_rest_table_index` appear in the documentation of
`sage.combinat.designs.difference_families`.
> * The function doesn't seem to do very interesting things for classes
which have
> inherited most of their methods. Is this by design?
It was designed to only show the 'first-level' functions, i.e. not the
inherited ones.
> Instead of using `root.__dict__`, then `dir(root)` would find
everything and
> his grandmother. Could that be more clever? Here the check
> `inspect.getmodule(root) == ...` also seems to get in the way for
listing
> class methods.
If you find a nice way to make it work, I have no objection for as long as
both remain available. The list of methods of 'graph' is already long
enough:
http://doc.sagemath.org/html/en/reference/graphs/sage/graphs/graph.html
You don't want to see its functions mixed with those:
http://doc.sagemath.org/html/en/reference/graphs/sage/graphs/generic_graph.html
Of course this index of functions is 'hand-made' so the example does not
apply. But there are other places where I would like to have an index of
functions: many classes inherit from IncidenceStructure, and I would not
want to see the methods of IncidenceStructure repeated everywhere.
In this situation, it would be more efficient to list only the first-level
methods, and have links saying what this class inherits from, so that
users can find the other methods easily.
This way we also avoid seeing the usual broken functions "which should not
be inherited but are nevertheless" like
{{{
sage: Partitions(4).base_ring
sage: Partitions(4).objgen
sage: Partitions(4).objgens
...
}}}
Nathann
--
Ticket URL: <http://trac.sagemath.org/ticket/18926#comment:9>
Sage <http://www.sagemath.org>
Sage: Creating a Viable Open Source Alternative to Magma, Maple, Mathematica,
and MATLAB
--
You received this message because you are subscribed to the Google Groups
"sage-trac" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/sage-trac.
For more options, visit https://groups.google.com/d/optout.
