#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: Travis
Scrimshaw
Authors: Simon King | Merged in:
Dependencies: | Stopgaps:
------------------------------------------------+---------------------------
Changes (by tscrim):
* reviewer: => Travis Scrimshaw
Comment:
Hey Simon,
Replying to [comment:9 SimonKing]:
> Replying to [comment:8 tscrim]:
> > 1. When are the argspec functions called, during compile, and roughly
by what?
> [...]
> 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.
Ah I see. That clarifies things for me. Thank you.
> 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).
So it's not a requirement to actually check bad syntax, but only needs to
guarantee that it will parse correct syntax. Correct?
> > 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`.
Sorry I was unclear; I was thinking of if the function was in python:
{{{
sage: def test(): return 1
....:
sage: def f(x,y={test():2},**kwds): pass
....:
sage: sage_getargspec(f)
ArgSpec(args=['x', 'y'], varargs=None, keywords='kwds', defaults=({1:
2},))
}}}
I think I'm now starting I understand what the issue is. However I don't
see how evaluating the default argument string in the modules namespace
could cause an issue unless the user directly calls
`_sage_getargspec_cython()` as you are in the tests. (I guess there is
also some difficulty in parsing out functions `foo(args)` and replacing it
with `module.foo(args)`...)
> > 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.
:D
> > 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.
Thanks.
> > 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?
Here's the topic: https://groups.google.com/forum/?fromgroups=#!topic
/sage-devel/P35X-WjDuK4
Thank you for clarifying things and answering all of my (crazy/misguided)
questions,[[BR]]
Travis
--
Ticket URL: <http://trac.sagemath.org/sage_trac/ticket/14017#comment:10>
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.
