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
Determine argspec of static methods with defaults in Cython files #16309
Comments
comment:1
That's really silly, as the names and defaults are easy to get:
|
comment:2
People have complained about We wouldn't need to hack that badly. We can just go with ducktyping: if It's been noted that testing for |
comment:3
Replying to @nbruin:
Indeed it is a bit odd that the inspect module does type checks rather than duck typing.
That's an important information, that I will use in #16296 for the Anyway, I suppose we need to somehow copy what is done in the inspect module, replacing the type check by duck typing. |
comment:4
It gets worse.
However, the source of
This should include the decorator! |
comment:5
Replying to @simon-king-jena:
Are you sure? Getsource does exactly what You are correct in noting that |
comment:6
Replying to @nbruin:
OK, good point. I think it would be odd to fix that on our side. |
comment:7
Inserting the following if hasattr(obj, 'func_code'):
try:
args, varargs, varkw = inspect.getargs(obj.func_code)
return inspect.ArgSpec(args, varargs, varkw, obj.func_defaults)
except (TypeError, AttributeError):
pass then the problem is solved for static methods of Python classes defined in Cython code, however it is not solved for static methods of cdef classes and cpdef methods of cdef classes. |
comment:8
Next problem:
Shouldn't the file end with |
comment:9
Problem, that is probably the reason why sage_getargspecs has problems:
and this (as I just found) boils down to this:
The expected result is
|
Branch: u/SimonKing/ticket/16309 |
Commit: |
comment:11
With the new branch, most problems mentioned here are fixed (and tested against), but the following remains a problem
New commits:
|
comment:12
Hmm. At the moment, I tend to say that this already needs review. The problem described in the previous comment only occurs of Hence, as long as all classes in Sage get a docstring, we will have no problem. And the fix should be enough for #16296. |
Author: Simon King |
comment:13
The following should be fixed, since it causes other trouble with #16296:
So, it detects Moreover, it cannot get the source lines of |
comment:14
Catching the So, what we should learn: Always provide a docstring! |
Branch pushed to git repo; I updated commit sha1. New commits:
|
comment:16
So far, I have no idea how to find the sources of a class that is defined in a Cython file, has no docstring and inherits a documented Note that a nested class defined in a Cython file does not have a dot in its name. However, Cython provides an attribute I suppose now it can really be reviewed. It will be essential for Cythoning sage.categories.category. |
Reviewer: Travis Scrimshaw |
comment:18
Hey Simon, Once you remove line 1643:
as it is unused in the doctest, LGTM and you can set a positive review. |
Changed branch from u/SimonKing/ticket/16309 to u/tscrim/argspec_static_methods-16309 |
comment:19
I've removed the line from the doctest and since it is a trivial change, I'm going to set this to positive review.
New commits:
|
Changed branch from u/tscrim/argspec_static_methods-16309 to |
Fix this:
This does not happen if
join
is a bound or unbound (not static) method.Since this will affect building the docs (see #16296), I'd say the component is "documentation".
CC: @nthiery
Component: documentation
Keywords: staticmethod cython argspec
Author: Simon King
Branch/Commit:
143b567
Reviewer: Travis Scrimshaw
Issue created by migration from https://trac.sagemath.org/ticket/16309
The text was updated successfully, but these errors were encountered: