Thanks, I added your testcases to #14272.
--
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 sage-devel+unsubscr...@googlegroups.com.
To post to this group, send emai
On Thu, May 09, 2013 at 12:00:16AM +0200, Jeroen Demeyer wrote:
> I should add that the doctest syntax you are using should work with
> the standard Python doctest module. That is: if whatever syntax
> you're using works with the Python doctesting framework, but not
> with Sage, then that's a bug w
On 05/08/2013 11:55 PM, Nicolas M. Thiery wrote:
Hi Jeroen, David,
Thanks for the quick feedback, and for improving doctests reports!
Do you agree with the following summary of the situation:
- Doctests in strings not directly attached to a class or a function
definition, like those
Hi Jeroen, David,
Thanks for the quick feedback, and for improving doctests reports!
Do you agree with the following summary of the situation:
- Doctests in strings not directly attached to a class or a function
definition, like those used with global options or for testing
attribute
On 05/08/2013 08:51 PM, Nicolas M. Thiery wrote:
This is not anymore possible. Finally, with the new global options,
it's natural to feed documentation to the option parser as strings,
and those strings contain examples. We would want them to be tested!
(see sage.combinat.partitions).
I'm hoping
> Is there a compelling reason for why the new doctesting insists on
> taking indentation into account? And in general in not taking each and
> every multiline string in the file as a docstring where to get
> doctests from?
>
The reason is to be able to identify what function is being tested: when
Dear doctest framework team,
Let me start by thanking the doctest team for the new framework! Even
just from a speed point of view, it's great.
On Mon, May 06, 2013 at 08:34:43PM -0700, Ben Hutz wrote:
> Thanks that helped. Actually, it does appear that four tests are not
> bei
