Consider the following:

sage: from sage.misc.sageinspect import sage_getfile, sage_getsource
sage: sage_getsource(integrate) in open(sage_getfile(integrate),'r').read()
True

This is good: the source actually occurs as a substring in the file 
reported to contain the source. We're not so lucky with certain wrapped 
functions:

sage: sage_getsource(hyperbolic_triangle) in 
open(sage_getfile(hyperbolic_triangle),'r').read()
False

The problem here is that the source is found via 
hyperbolic_triangle._sage_src_lines_() which reports the source of the 
wrapped function as well as the starting line number in the source file, 
but the source file of the wrapped function does not seem to be available 
in any way. Shouldn't we be saving that information too somewhere, so that 
sage_getfile can work in a way that is consistent with sage_getsource?

Presently, invoking obj._sage_src_lines_() is preferred in 
sage_getsourcelines [it's tried first] whereas sage_getfile first tried to 
extract a file from the docstring (as required for cython functions) and 
for non-classinstances, reverts to inspect.getabsfile, which will probably 
just look at obj.func_code.co_filename (which of course belongs to the 
wrapper, not the wrapped object). It seems to me that we should have an 
obj._sage_src_file_ to accompany the obj._sage_src_lines_ protocol , or 
extend the tuple returned by obj._sage_src_lines_ to also include the file 
name (as a third entry probably).

Cheers,

Nils

-- 
You received this message because you are subscribed to the Google Groups 
"sage-devel" 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-devel.
For more options, visit https://groups.google.com/d/optout.

Reply via email to