How to doctest a pyx file?

[Simon King]

Dear Sage support,

I am a bit puzzled since very similar things worked in the past.

- I have a Cython extension module in a package that is installed in
SAGE_LOCAL/lib/python2.5/site-packages/ and can be imported when
starting sage, doing
sage: from pGroupCohomology import mtx
- I want to test the corresponding mtx.pyx
- Doing
sage -t -long -optional mtx.pyx
in the directory where mtx.pyx sits failed badly!

The errors that I get have nothing to do with the doc tests.
Apparently, when doing sage -t ... mtx.pyx, it is tried to compile
mtx.pyx, which fails since the compilation depends on external C-
sources.

Why is it attempted to compile? I thought that sage -t just scans the
file for doc tests?

Note that things worked in the past, when I had the following:
- mtx.so was in the current directory
- I set SAGE_PATH to the current directory
- I did sage -t -long -optional mtx.pyx

What is the difference?

Best regards,
Simon

[Simon King]

Hi!

On 19 Jun., 10:30, Simon King <simon.k...@uni-jena.de> wrote:
> Note that things worked in the past, when I had the following:
> - mtx.so was in the current directory
> - I set SAGE_PATH to the current directory
> - I did sage -t -long -optional mtx.pyx
>
> What is the difference?

Apparently the difference lies in Sage and not in my tests. I just
tried again the exact setting in which testing my extension modules
used to work -- now it fails, since "sage -t mtx.pyx" tries to compile
mtx.pyx for whatever reason.

Couldn't "sage -t" just take any text file, search for "sage:" prompts
etc, and verify the output?

Another idea.

Let "knight" be a (python) package or module. Is there a function
(say, recursive_doc_test) in Sage that does the doc tests for "knight"
and, recursively, for its contents (functions; classes; methods of
these classes; other modules, if knight is a package; ...) and returns
the results of the test as a string? I mean
sage: import knight
sage: recursive_doc_test(knight)
'The following items had faiilures:
In knight.Ni.Shrubbery, l. 12:
expected:
"herring"
got:
nothing
...'

The line number would refer to the 12th line in the doc string of the
class knight.Ni.Shrubbery, say.

Is there anything of that kind in sage? Should there be?

The disadvantage would be that "recursive_doc_test" probably couldn't
test cdef-methods.

Cheers,
Simon

[gsw]

On 20 Jun., 08:15, Simon King <simon.k...@uni-jena.de> wrote:
> Hi!
>
> On 19 Jun., 10:30, Simon King <simon.k...@uni-jena.de> wrote:
>
> > Note that things worked in the past, when I had the following:
> > - mtx.so was in the current directory
> > - I set SAGE_PATH to the current directory
> > - I did sage -t -long -optional mtx.pyx
>
> > What is the difference?
>
> Apparently the difference lies in Sage and not in my tests. I just
> tried again the exact setting in which testing my extension modules
> used to work -- now it fails, since "sage -t mtx.pyx" tries to compile
> mtx.pyx for whatever reason.
>

Hi Simon,

first of all: yes, you are right. A few versions ago, "sage -t ..."
worked differently. I dimly remember one or two threads on sage-devel
about people wanting to doctest arbitrary files in arbitrary
directories, which didn't work as they expected back then.

If I understand it correctly, the doctesting mechanism was changed, to
be part of (or to make use of) the "load/attach" mechanism of Sage ---
so if you can successfully "load" foobar.pyx into Sage, you also
should be able to doctest it, with current Sage versions. But for most
stuff which is greater than one file, the current behaviour is worse
than it was before and is a regression IMHO.

And also for me, these code changes did break some setup of mine,
where I had installed own stuff in .../python/site-packages/...

I could make doctesting my code (extension modules) work again in two
hours or so mainly by inserting some of these infamous "#clib ..."
"#cinclude ..." poor-man's pragmas I heartily dislike.

If you wish, we could discuss this topic further and in depth on sage-
devel (where it belongs), just open a thread there.

> Couldn't "sage -t" just take any text file, search for "sage:" prompts
> etc, and verify the output?
>

I didn't check it, but if you move all your doctests out of a *.pyx
file into another file --- say a *.py file with the necessary
"import"s --- then doctesting this new file should work fine. At least
for me, this is not an alternative, because I want to have the
doctests in the very same file and as close to the source code lines
they test.

> Another idea.
>
> Let "knight" be a (python) package or module. Is there a function
> (say, recursive_doc_test) in Sage that does the doc tests for "knight"
> and, recursively, for its contents (functions; classes; methods of
> these classes; other modules, if knight is a package; ...) and returns
> the results of the test as a string? I mean
>   sage: import knight
>   sage: recursive_doc_test(knight)
>   'The following items had faiilures:
>    In knight.Ni.Shrubbery, l. 12:
>    expected:
>        "herring"
>     got:
>        nothing
>    ...'
>
> The line number would refer to the 12th line in the doc string of the
> class knight.Ni.Shrubbery, say.
>
> Is there anything of that kind in sage? Should there be?
>

Doctesting is done on the shell level. There, you can say "sage -t
mydir/" and all the files under "mydir" and its subdirectories are
doctested in one go. Since python modules are grouped hierarchically,
this comes very close to what you described. Any shell commands may be
issued from inside Sage (since you can from within Python: "os.system
("command arguments")", and the output piped into a file or what you
like. So essentially, everything is already there and available. But
kind of low-level ...

> The disadvantage would be that "recursive_doc_test" probably couldn't
> test cdef-methods.
>

If inside Sage something "polished" existed as you describe it, most
probably one *could* doctest cdef-methods with it. At least it should
be written this way IMHO.

Cheers,
gsw

> Cheers,
>     Simon

[Simon King]

Hi!

On 20 Jun., 22:10, gsw <GeorgSWe...@googlemail.com> wrote:
> If you wish, we could discuss this topic further and in depth on sage-
> devel (where it belongs), just open a thread there.

In the first place, I thought it was a support problem, because I
thought that testing any text file should be simple (and used to
work), and I simple wasn't aware how it works.

Anyway: http://groups.google.com/group/sage-devel/browse_thread/thread/3f9c8660ed742303

Cheers,
Simon