>
> The docstring for doctest.DocTestRunner contains the example code
>
> I was looking for.
>
>
Thanks, I will give it a try!
>
> --
>
> Neil Cerutti
--
https://mail.python.org/mailman/listinfo/python-list
On 2013-09-23, Luca Cerone wrote:
>> It won't be very good documenation any more but nothing stops you
>>
>> from examining the result in the next doctest and making yourself
>>
>> happy about it.
>>
>>
>>
>> >>> x = input("indeterminate:")
>>
>> >>> result = "'{}'".format(x))
>>
>> >
On 2013-09-23, Neil Cerutti wrote:
> Perhaps try the "advanced API" and define your oen
> OutputChecker to add the feature that you need.
>
> Figuring out how to best invoke doctest with your modified
> OutputChecker will take some digging in the source, probably
> looking at doctest.testmod. I do
> I don't know why but it seems that google groups stripped the indentation
> from the code.
Because it's Google Groups. :-)
800-pound gorillas tend to do pretty much whatever they want.
Skip
--
https://mail.python.org/mailman/listinfo/python-list
I don't know why but it seems that google groups stripped the indentation from
the code. I just wanted to ensure you that in the examples that I have run
the definition of myfunc contained correctly indented code!
On Monday, 23 September 2013 15:45:43 UTC+1, Luca Cerone wrote:
> .. doctest:: exa
> It won't be very good documenation any more but nothing stops you
>
> from examining the result in the next doctest and making yourself
>
> happy about it.
>
>
>
> >>> x = input("indeterminate:")
>
> >>> result = "'{}'".format(x))
>
> >>> result.startswith("'") and result.endswith("'
On 2013-09-22, Luca Cerone wrote:
> I understand your point, but now I am not writing unit tests to
> check the correctness of the code. I am only writing a tutorial
> and assuming that the code is correct. What I have to be sure
> is that the code in the tutorial can be executed correctly, and
>
On Sun, 22 Sep 2013 09:39:07 -0400, Ned Batchelder wrote:
> On 9/22/13 12:09 AM, Luca Cerone wrote:
>> Hi Chris,
>> actually my priority is to check that the code is correct. I changed
>> the syntax during the development, and I want to be sure that my
>> tutorial is up to date.
>>
>>
> If you do
On Sunday, 22 September 2013 14:39:07 UTC+1, Ned Batchelder wrote:
> On 9/22/13 12:09 AM, Luca Cerone wrote:
>
> > Hi Chris,
>
> > actually my priority is to check that the code is correct. I changed the
> > syntax
>
> > during the development, and I want to be sure that my tutorial is up to
> This makes no sense. If you ignore the output, the code could do ANYTHING
>
> and the test would still pass. Raise an exception? Pass. SyntaxError?
>
> Pass. Print "99 bottles of beer"? Pass.
>
if you try the commands, you can see that the tests fail..
for example
.. doctest::
>>> rais
On 9/22/13 12:09 AM, Luca Cerone wrote:
Hi Chris,
actually my priority is to check that the code is correct. I changed the syntax
during the development, and I want to be sure that my tutorial is up to date.
If you do manage to ignore the output, how will you know that the syntax
is correct?
On Sat, 21 Sep 2013 21:15:48 -0700, Luca Cerone wrote:
> I am looking for a way to test the code while ignoring the output.
This makes no sense. If you ignore the output, the code could do ANYTHING
and the test would still pass. Raise an exception? Pass. SyntaxError?
Pass. Print "99 bottles of
On Sun, Sep 22, 2013 at 2:09 PM, Luca Cerone wrote:
>> but if you're using this for a
>>
>> tutorial, you risk creating a breed of novice programmers who believe
>>
>> their first priority is to stop the program crashing. Smoke testing is
>
> Hi Chris,
> actually my priority is to check that the c
>
> That is not how doctest works. That test fails because its output is:
ok.. is there a tool by which I can test if my code runs regardless the output?
>
> The only wild-card output that doctest recognises is ellipsis, and like
>
> all wild-cards, can match too much if you aren't careful. I
> but if you're using this for a
>
> tutorial, you risk creating a breed of novice programmers who believe
>
> their first priority is to stop the program crashing. Smoke testing is
Hi Chris,
actually my priority is to check that the code is correct. I changed the syntax
during the development,
On Sat, 21 Sep 2013 09:25:26 -0700, Luca Cerone wrote:
>> And if you ignore the output, the error won't be caught either. What's
>> the difference?
>>
>> >>> 1 + 1 #doctest:+IGNORE_OUTPUT (not a real directive)
>> 1000
>>
>>
> The difference is that in that case you want to check whether the
On Sun, Sep 22, 2013 at 2:25 AM, Luca Cerone wrote:
> The difference is that in that case you want to check whether the result is
> correct or not, because you expect a certain result.
>
> In my case, I don't know what the output is, nor care for the purpose of the
> tutorial. What I care is bei
> And if you ignore the output, the error won't be caught either. What's
>
> the difference?
>
> >>> 1 + 1 #doctest:+IGNORE_OUTPUT (not a real directive)
>
> 1000
>
>
The difference is that in that case you want to check whether the result is
correct or not, because you expect a certain r
On Sat, 21 Sep 2013 05:44:09 -0700, Luca Cerone wrote:
> If you use a SKIP
> directive on code that contains a typo, or maybe you changed the name of
> a keyword to make it more meaningful and forgot to update your
> docstring, then the error won't be caught.
And if you ignore the output, the err
Dear Steven,
thanks for the help.
I am aware that I might have used the SKIP directive (as I hinted in my mail).
Even if the fine manual suggests to do so I don't agree with it, though.
The reason is simple: SKIP as the name suggests causes the code not to be run
at all, it doesn't ignore the out
On Sat, 21 Sep 2013 03:47:26 -0700, Luca Cerone wrote:
> Dear all,
> I am writing the documentation for a Python package using Sphinx.
>
> I have a problem when using doctest blocks in the documentation: I
> couldn't manage to get doctest to run a command but completely ignoring
> the output.
>
Dear all,
I am writing the documentation for a Python package using Sphinx.
I have a problem when using doctest blocks in the documentation:
I couldn't manage to get doctest to run a command but completely ignoring
the output.
For example, how can I get a doctest like the following to run correct
22 matches
Mail list logo
