New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Auto-generated index of functions #18926
Comments
New commits:
|
Commit: |
Branch: public/18926 |
comment:2
CC'ing myself because of #18636. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:5
Just to make sure: there is no way to skip all deprecated functions? On The code seems to be clear. However, I know nothing about introspection in python, so hopefully somebody else will review this. |
comment:6
I already filter out those that I can identify. If you see a way to remove others, we can add it. Nathann |
comment:7
Hi Nathann Clever idea and nice code. I like it. A few small comments:
Johan |
comment:9
Hellooooooooooo !
Thanks. I like it too
Sorry. Fixed.
Good idea, done.
The imported modules. If you remove it, you will see
It was designed to only show the 'first-level' functions, i.e. not the inherited ones.
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
Nathann |
comment:12
Helloooooooooooooooo Nathannnnnnnn, For some reason, I can't pull from trac.sagemath.org right now - connection timeout. So I can't get your newest version and run the tests. I see what you're saying about the locally defined functions. To support I'd push this change myself if trac was working for me right now. I also wanted to suggest some further polishing of the docstrings. I'll push that as soon as I can again connect to trac.sagemath.org. Johan |
comment:14
Hi Nathann, Now the trac firewall has been doused, I've corrected the small things I mentioned. From my side, I give the ticket a green light now. So you can review my small changes :-) Johan |
comment:15
Helloooooo Johan, I have several remarks about your commits:
Nathann |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:18
Hiiiiii Nathann,
Oh, sorry, didn't check that. Fixed.
Fixed.
Yes, it's slightly bizarre. Say you have a catalog module that you wish to have
The function only extracts methods of a class which have been decorated with
This line was just to clarify the semantics of the function wrt. classes, since Johan New commits:
New commits:
|
comment:19
Helloooooooo,
Oh okay, it is true that somehow this function has a 'special behaviour'. Would you see anything wrong in filtering it out with
Whaaaaat? None of the methods of
Oh. What about renaming it to 'only_local_functions` to make it plain(er) that it does not apply to methods? Nathann |
comment:20
No, that's probably simpler. I did the other check in case more functions are added to the module, but now I realise that even if that happens, multiple such functions are probably not imported into the same module.
Ok... It seems I've been on drugs (benadryl). I know that it was some class in combinat.posets that made me think this, and I though I tested it. I must have messed it up with the inherited-methods-not-included thing...
Yeah, that's a good idea. |
Branch pushed to git repo; I updated commit sha1. New commits:
|
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:23
Hellooooo ! I cleaned/simplified a couple of things. Also, it seems that this code catalog of yours did not compile anymore and the functions appeared twice. Is it okay for you now? I do not see anything to add, on my side. Nathann |
Reviewer: Johan Sebastian Rosenkilde Nielsen |
comment:24
Sorry for the mess. Yes, it is ok for me now. |
comment:25
Exxxxxxxxxcellent. Thanks. We now have free index of functions, nothing to do by hand. Cool. Nathann |
comment:26
And thank you very much for your help!!! Nathann |
comment:27
Yes it's very nice :-) I though several times that such a thing would be good to have but I was a bit daunted with the prospects of picking into Sphinx internals. Your solution is very neat. |
Changed branch from public/18926 to |
This branch implements a new function named
gen_rest_table_index
which generates an index of the functions given as arguments.It can also generate the list of all methods of a given class
A
.With this functions, it is then very easy to add an index of functions in a Sage module, that does not have to be kept updated manually.
Nathann
CC: @dcoudert @jm58660 @sagetrac-dlucas
Component: documentation
Author: Nathann Cohen
Branch/Commit:
37011a4
Reviewer: Johan Sebastian Rosenkilde Nielsen
Issue created by migration from https://trac.sagemath.org/ticket/18926
The text was updated successfully, but these errors were encountered: