-
-
Notifications
You must be signed in to change notification settings - Fork 453
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
Decorated functions/methods have generic signature in documentation #9976
Comments
Fixes the issue by patching Sage's version of Sphinx to look for a custom attribute in functions and methods. |
comment:1
Attachment: trac_9976_decorated_generic_sigs.patch.gz Note that the attached patch assumes Trac #9907 (which in turn assumes #9919). Sorry for the chain of Tracs, but I believe the others are just about finished, so it seems like wasted extra work to first make a version without the dependency and then patch this. |
comment:2
Now I've finished, cleaned up and tested an alternative patch. It is a slightly more invasive change to the Sphinx autodoc algorithm, and it is a little less intuitive than the other, but it makes it easier for decorators to change the signature of the wrapped function (currently, only In the other patch we used the attribute _sage_decorating which returns the wrapped function to tell Sphinx that it should behave specially, but in the new patch, the decorating callable should now instead define an attribute _sage_getargspec. This should be a function returning an argspec (an argspec is an python.inspect.ArgSpec tuple as returned by python.inspect.getargspec -- basically describing the elements of a function's signature) with the help of an "argspec-retrieving function" taken as argument. This recursive way of doing things is for avoiding the logic within Sphinx of getting the argspec for various types of functions (e.g. Python, Cython or built-in). When Sphinx is asked to format the signature of a function, and that function defines _sage_getargspec, it formats in a standard way whatever _sage_getargspec(getter) returns, where getter is basically itself (that is, the Sphinx function currently being asked to find the argspec of some function). So for example, |
comment:4
I personally prefer the advanced and intrusive patch as it allows more flexibility for the usual developer. I hope that decorators could be more widely used after this patch is introduced, as they are really handy for many things. |
This comment has been minimized.
This comment has been minimized.
comment:9
I am currently working on a related problem, namely a Cython version of the cached_method decorators - see #11115. Why is that related? What one would like to do in this case is to preserve the documentation (and also the source code, file and argspec) of the wrapped function. But if it is Cython, one can not simply override The obvious solution is to consequently use So, what I would like to do is to edit But shall I post that here, since it is related? Or shall I open a new ticket, since, after all, the patch here does not touch Best regards, Simon |
comment:10
Replying to @simon-king-jena:
Oops, me stupid! I just realised that I was not editing I guess that means that I should post my patch here, right? Best regards, |
comment:11
The part about decorators shadowing Cython callable's doc, source code, file, etc. definitely sounds like the same. I guessed that something similar would be wrong with Cython, but I don't write Cython so it was tedious to try and dig up. Good that you came across it. I don't see why this ticket shouldn't encompass both patches for completeness. I guess that your sage_autodoc patch is not about the cache functionality of your Cheers, |
comment:12
Replying to @johanrosenkilde:
Of course! This ticket will eventually become a dependency for #11115. What I intend to do: Modify the
If that is fixed (similarly in the other Best regards, Simon |
comment:13
What I would like to have is:
Then, using
So, if the decorator has |
comment:14
I see this error when building the documentation:
Admittedly this is after I edited sage_autodoc to use more from sageinspect. However, it concerns a part that I did not touch, namely apparently the method |
comment:15
How is the documentation of a class, method etc. actually obtained? There is a method Could it by the the work is done by the method By consequence, if one has a method that is decorated by a cython class (something that I plan for the cached_method decorator) then the documentation will be that of the cython class, not that of the decorated method. So, could it be that we have to replace |
comment:16
Replying to @simon-king-jena:
I don't know about that error. On my current version of sage 4.6.2 it applies and compiles with no problems; I am currently updating to 4.7.alpha3 to test it there... |
comment:17
Replying to @simon-king-jena:
That is indeed surprising; I would have thought that was constructing the documentation. You are aware that there are two get_doc functions: one in the Documenter class (which is the father of all documenters), and the overwritten in the ClassLevelDocumenter subclass? So if you were monitoring Documenter's get_doc but were for the documentation of a method or attribute, you would not see the call (I'm compiling, so I can't test myself just now).
I hope not. For this ticket, I originally only looked at where the argument string was formatted and that is in sage_autodoc.py. ModuleAnalyzer is (only?) called on line 624 (unpatched) with the following comment: "try to also get a source code analyzer for attribute docs". If what you are suggesting above is true, we should be able to wrap these lines with some exceptions in the cases where a _sage_doc attribute has been set on the object. |
comment:18
Replying to @johanrosenkilde:
I inserted commands into both Then, I bumped it up, and inserted a So, I must conclude that neither version of |
comment:19
Replying to @simon-king-jena:
No, the reason for that behaviour is that apparently the documentation is cached on disk. In other words, I had to delete the html file and to touch the code from which the documentation was taken, and to do "sage -b". After that preparation, things worked. My question to you: How can I completely wipe the cache? I have to leave office now. But I guess a bit later today, or tomorrow, I will be able to provide a patch on top of yours. Its purpose is to allow for Cython objects to provide a documentation that is different from the documentation of their class, and it also provides the possibility to inspect Cython code that is defined during an interactive session. |
comment:20
I added a patch that ought to be applied on top of the previous patch. In Moreover, it makes
Then, it also allows inspection of Cython code that is defined in an interactive session. Its code is defined in a temporary file, thus, not in the sage library tree. But the old algorithm would only try to find files in the library tree.
I am building the documentation from scratch. If it works then I can give your patch a positive review. And I hope there will be a reviewer for my patch as well... But careful, my patch modifies something in the sage library, so, doc tests are needed. For the patchbot: Apply trac_9976_decorated_generic_sigs_alternative.patch 9976-inspection_of_cython.patch |
This comment has been minimized.
This comment has been minimized.
Changed keywords from sphinx to sphinx, cython inspection |
Changed author from jsrn to jsrn, Simon King |
Attachment: 9976-inspection_of_cython.patch.gz Improve inspection on Cython objects, functools.partial and other class instances; let sage_getargspec return an ArgSpec?; improve argument parsing; let a plot raise an AttributeError? if an attribute is missing; include cached functions in references |
comment:170
I have updated my inspection_of_cython patch, by providing two dynamical tests for functools.partial (namely sage_getdoc and sage_getargspec). Such dynamical tests are impossible for sage_getfile and sage_getsource, since interactive Python code won't create a source file to inspect. I already gave your patches a green light. So, I hope you are happy with my patches as well... |
comment:171
Great, very nice. Everything applies and works fine here, and I already looked through everything more than once. It's a-go. |
Changed reviewer from Simon King to jsrn, Simon King |
comment:173
Please change the commit message of attachment: trac_9976_decorated_generic_sigs_alternative.patch (use |
Changed reviewer from jsrn, Simon King to Johan Sebastian Rosenkilde Nielsen, Simon King |
Changed author from jsrn, Simon King to Johan Sebastian Rosenkilde Nielsen, Simon King |
Attachment: trac_9976_decorated_generic_sigs_alternative.patch.gz Alternative patch: more intrusive Sphinx patch which makes it easier to let decorators change the signature of the wrapped function. |
comment:176
Fixed commit message. |
Merged: sage-4.7.1.alpha0 |
Patch rebased to sage-4.7 |
This comment has been minimized.
This comment has been minimized.
comment:178
Attachment: 9976_doc_fixes_v2.patch.gz |
Functions or methods that have been decorated by generic decorators such as sage.misc.decorators.options (moved from sage.misc.plot.options with Trac #9907) degrade documentation by reducing the signature for these callables to the generic "(*args, **kwargs)".
See also the following sage.devel discussion: http://groups.google.com/group/sage-devel/browse_thread/thread/cbd888f0e60130ff/f533792113c45c2f
Let's say that the advanced patch is the most useful and scalable. So ignore the first one and:
Apply
Note that the last patch belongs to a different repository!
CC: @jasongrout @kcrisman @jhpalmieri @novoselt
Component: documentation
Keywords: sphinx, cython inspection
Author: Johan Sebastian Rosenkilde Nielsen, Simon King
Reviewer: Johan Sebastian Rosenkilde Nielsen, Simon King
Merged: sage-4.7.1.alpha0
Issue created by migration from https://trac.sagemath.org/ticket/9976
The text was updated successfully, but these errors were encountered: