On 2013-09-22, Luca Cerone luca.cer...@gmail.com 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
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(')
True
Hi Neil,
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::
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
On 2013-09-23, Neil Cerutti ne...@norwich.edu 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
On 2013-09-23, Luca Cerone luca.cer...@gmail.com 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))
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 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 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?
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::
raise
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
date.
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 manage to
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
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.
For
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
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 error
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 result.
In
On Sun, Sep 22, 2013 at 2:25 AM, Luca Cerone luca.cer...@gmail.com 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.
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 result
is
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, and
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. If
On Sun, Sep 22, 2013 at 2:09 PM, Luca Cerone luca.cer...@gmail.com 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
22 matches
Mail list logo
