#14017: Determine the correct argspec for python functions defined in cython
files
------------------------------------------------+---------------------------
Reporter: SimonKing | Owner: jason
Type: defect | Status: needs_review
Priority: major | Milestone: sage-5.7
Component: misc | Resolution:
Keywords: introspection cython argspec | Work issues:
Report Upstream: N/A | Reviewers:
Authors: Simon King | Merged in:
Dependencies: | Stopgaps:
------------------------------------------------+---------------------------
Comment (by SimonKing):
Hi Travis,
Replying to [comment:8 tscrim]:
> 1. When are the argspec functions called, during compile, and roughly by
what?
The argspec functions have of course nothing to do with compilation. Their
main use cases seem to be:
* Creation of the docs. If you look into the Sage reference, you will see
that any function or method shows its arguments. I think the documentation
would not change with my patch, because from the point of view of
documentation, it simply does not matter whether the method
{{{
def foo(self, int n, *args):
...
}}}
has an argument name `*args` (including the `*`!!) or has varargs named
`args` (ecluding the `*`).
* Decorators. The reason for creating this patch is the cached_method
decorator. Let foodec be obtained by applying the cached_method decorator
to a method foo. When calling foodec, it is needed to determine the names
of the arguments of foo, ''including'' varargs and keywords. This is done
only once, of course.
> 2. Would this be caught as an error by the cython compiler (or any other
bad syntax for that matter)?
What would be caught as an error? It really seems you are confusing some
things. The compiler did its work already. sage_getargspec (or
inspect.getargspec) is called on functions or methods. In the case of
Python functions, inspect.getargspec can determine the arguments of a
function by certain attributes that the function provides.
But in the case of a Cython function (def or cpdef), these attributes do
not exist. Hence, sage_getargspec will try to find the source code (via
sage_getsource) and determine the argument list from the source.
Before my patch, the parsing process used to fail on typical function
definitions in Cython -- as shown in the ticket description. With my
patch, the arguments are correctly determined from the source code.
Relation with the compiler:
Let s be a string, which is some code supposed to define a function.
If `_sage_getargspec_cython(s)` raises a syntax error, then Cython is
supposed to refuse compilation of s. Hence, `_sage_getargspec_cython(s)`
will ''never'' raise an error on the source code of a successfully
compiled function (otherwise it would be a bug).
> 3. Would `_sage_getargspec_from_ast` would parse it correctly?
Cython code can look like `"def foo(b, int a=1, *args)"`.
`_sage_getargspec_from_ast` would not know what to do with that string. As
I have explained in some post above, the new `_sage_getargspec_cython`
will strip the type definitions; hence, it would first transform it into
`"def dummy(b,a=1,*args)"` and then call `_sage_getargspec_from_ast`.
> As a general design note, I would think all `sage_getargspec*` functions
should return the same data in the same format (in regard to [comment:5
your comment here]).
That's what my patch does.
> As for the patch, two quick things. Is there any reason to have that
large commented out code block?
Oops, sorry, I'll remove that block and will submit a new patch after
dinner.
> Also I believe we should try to be python 3 compliant as much as
possible, so the exceptions should be `raise ExceptionType("msg")`.
Never heard of that rule. Could you ask on sage-devel whether this rule
should be encouraged?
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14017#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?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
