Doctests

[videlec]

The branch

• fix the travis script
• converts all Sage doctest to Python doctests
• fix many doctest failures with Python 2.7

See also trac #22899 for the doctests that will be directly moved to Sage.

[jdemeyer]

Why did you change the formatting of the doctests (apart from just changing sage: to >>>)? This is going to look bad if we would process the documentation with Sphinx.

[videlec]

The sage: to >>> is the minimum to have doctest works. The EXAMPLES and TESTS were Sage specific. What is the minimum to have sphinx compatible syntax? (some websites mention :Example: and others .. doctests::)

[jdemeyer]

What is the minimum to have sphinx compatible syntax?

The double colon as in EXAMPLES:: (but also Some other text:: would work), followed by an indented block.

[videlec]

What is the minimum to have sphinx compatible syntax?

The double colon as in EXAMPLES:: (but also Some other text:: would work), followed by an indented block.

Easy to fix. I propose to postpone this change after #13 (Python 3 compatibility).

@jdemeyer could you modify the travis script to check that building the documentation with sphinx works?

[jdemeyer]

could you modify the travis script to check that building the documentation with sphinx works?

I'll try to do that this week but I cannot promise anything.

[jdemeyer]

Actually, it turns out that Sphinx does understand the docstring style introduced in this PR. So nothing needs to be fixed...

[videlec]

very good. Could you have a look at #13 ?

[jdemeyer]

could you modify the travis script to check that building the documentation with sphinx works?

Done! And it actually works.

[defeo]

I just realised this doctests adds a useless dependency on six. Without the import, the doctest works just fine in Py2&3.
However, I'm not sure about the original intent of the test. Maybe replacing range(10) with list(range(10)) is closer to it.
Opinions? I shall start a separate pull request for this.

[jdemeyer]

I just realised this doctests adds a useless dependency on six.

You could do a similar thing as some other Python 2/3 doctests and just use sys.version (or whatever it's called). The idea is to get xrange in Python 2 and range in Python 3.

[defeo]

Oh, I see. I had interpreted it the other way round.

So a one line replacement compatible with both 2 & 3 would be objtogen(i for i in range(10)). But then this is redundant with the following doctest, we could as well remove it. I have the impression that it would be more interesting to replace it with objtogen(list(range(10)).

[jdemeyer]

So a one line replacement compatible with both 2 & 3 would be objtogen(i for i in range(10)). But

Not quite since (i for i in range(10)) is not the same as neither xrange(10) or range(10). Both are iterables yielding the same numbers, but it's not the same thing.