#9976: Decorated functions/methods have generic signature in documentation
--------------------------------+-------------------------------------------
Reporter: jsrn | Owner: mvngu
Type: enhancement | Status: needs_work
Priority: major | Milestone: sage-4.7
Component: documentation | Keywords: sphinx, documentation, cython
inspection
Author: jsrn, Simon King | Upstream: N/A
Reviewer: | Merged:
Work_issues: |
--------------------------------+-------------------------------------------
Comment(by SimonKing):
Replying to [comment:29 jsrn]:
> > As I mentioned above, I don't know much about Python conventions. But
I thought it is considered bad practice to provide that type of data by
arguments?
>
> Huh, why oh why? Ok, I never really read those conventions, but if you
say so ;-)
Well, I am no expert for Python conventions. It is just something that I
think to remember to have heard...
> Definitely, if that is the way Sage does it elsewhere; I weren't aware
of that. I'll look into changing my patch; what kind of stuff does
_sage_argspec_ usually return?
It is similar to the format that is returned by inspect.getargspec:
{{{
sage: def f(x,y, k=1,l=2, *args, **kwds): pass....:
sage: inspect.getargspec(f)
ArgSpec(args=['x', 'y', 'k', 'l'], varargs='args', keywords='kwds',
defaults=(1, 2))
sage: sage.misc.sageinspect.sage_getargspec(f)
(['x', 'y', 'k', 'l'], 'args', 'kwds', (1, 2))
}}}
So, `self._sage_argspec_()` should return a tuple of the kind that is
returned by `sage_getargspec(self)`.
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/9976#comment:32>
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 post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sage-trac?hl=en.
