Roundup Robot added the comment:
New changeset d012f645b8b2 by R David Murray in branch '3.2':
#14649: clarify DocTestSuite error when there are no docstrings.
http://hg.python.org/cpython/rev/d012f645b8b2
New changeset 6544fc92b528 by R David Murray in branch 'default':
Merge #14649: clarify
R. David Murray added the comment:
Thanks, Chris.
--
resolution: - fixed
stage: patch review - committed/rejected
status: open - closed
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
Roundup Robot added the comment:
New changeset c5fc49bc7a5f by R David Murray in branch '2.7':
#14649: add sample files omitted from previous checkin.
http://hg.python.org/cpython/rev/c5fc49bc7a5f
--
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Thanks a lot, David.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
___
Python-bugs-list mailing
Chris Jerdonek added the comment:
I tried applying the latest patch (patch #6) to 3.2, merging to default, and
then running all tests in default, and the tests seem to all pass for me (in
both default and 3.2). Also, the diff for the change in default after that
process seems to be identical
R. David Murray added the comment:
Ah, my mistake. I forgot to do the hg add for the new files.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
Chris Jerdonek added the comment:
What workflow/command are you using to apply and then merge the patch? I
didn't need to run hg add at any point to go from 3.2 to default, and run the
tests, etc.
--
___
Python tracker rep...@bugs.python.org
R. David Murray added the comment:
I have separate working directories for 3.2 vs 3.3. If you have a single
working directory, the files would continue to be present even without the add.
The add is definitely needed for a correctly committed changeset.
--
R. David Murray added the comment:
OK, 3.2 passes now, but when I merge to 3.3 I get failures.
test_zipimport_support doesn't work on 2.7 either, but there we could just not
backport the tests.
--
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
I prepared the patch against 3.3 (default), so I wouldn't have expected it to
work against 3.2 without further changes. The behavior in 3.3 after merging is
also surprising given that it worked in 3.2 (and for me with direct
application).
I will look into
R. David Murray added the comment:
With your patch 5 applied, test_zipimport_support fails. I took a quick look
at this and it looks like it is because we've added a dependency on an external
data file to the test for DocTestSuite.
Note that with patch 4 applied, test_pyclbr fails...I found
Chris Jerdonek added the comment:
With your patch 5 applied, test_zipimport_support fails.
You're right. It looks like test_zipimport_support is tightly coupled to
test_doctest. For example--
http://hg.python.org/cpython/file/786d9516663e/Lib/test/test_zipimport_support.py#l94
My
Chris Jerdonek added the comment:
I updated the patch to fix the test_zipimport_support tests. All tests now
pass. The only changes were to Lib/test/test_zipimport_support.py.
I'll make a note about test_pyclbr and test_zipimport_support when I create the
issue to move the supporting
Chris Jerdonek added the comment:
Updating the patch after discussing with David on IRC.
The two new files are now added to Lib/test instead of to a subdirectory of
Lib/test. Moving the doctest files to a subdirectory can be discussed and
possibly addressed as part of a separate issue.
Chris Jerdonek added the comment:
Personally I prefer to have the test case create the file(s) used in the test
dynamically, writing them to the temporary working directory.
I prefer that too, but when I approached this issue, I found that test_doctest
doesn't use unittest. It uses only
Chris Jerdonek added the comment:
Small tweak to a code comment in the patch (`tests` is not itself a
unittest.TestSuite instance).
--
Added file: http://bugs.python.org/file27000/issue-14649-4.patch
___
Python tracker rep...@bugs.python.org
Chris Jerdonek added the comment:
Here is an updated patch for review (just for the default branch for now).
The main change from the previous patch is that the ValueError exception is now
documented.
A few additional comments/questions:
Is there a better way to signify in the documentation
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
Added file: http://bugs.python.org/file26991/issue-14649-3.patch
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
R. David Murray added the comment:
Personally I prefer to have the test case create the file(s) used in the test
dynamically, writing them to the temporary working directory. Since these are
Python modules, you could use the helpers from script_helpers for this.
Otherwise I think your patch
Andrew Svetlov added the comment:
Ok, I'm +0 for that.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
___
Python-bugs-list mailing
Andrew Svetlov added the comment:
I think current behavior is correct.
Every doctest is docstring from tested module, but not every docstring is a
valid doctest.
--
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
R. David Murray added the comment:
Chris isn't suggesting changing the behavior, just the error message. I agree
with his change for exactly the reason you say: currently doctest doesn't
complain if a module does have docstrings but none of those docstrings are
tests. So a module could have
Chris Jerdonek added the comment:
Every doctest is docstring from tested module, but not every docstring is a
valid doctest.
Actually, I'm not sure even this is correct. doctest will form a unittest
*TestSuite* from a module if it has docstrings, but it will not necessarily
create a test
Chris Jerdonek added the comment:
I suspect the intent was to raise an error if there were no *tests*, not if
there were no docstrings.
That, or the implementor thought that if no docstrings were found, then that
might indicate something went wrong with the parsing.
For background
R. David Murray added the comment:
That's a good question. Perhaps you could argue for it as a bug fix since it
doesn't seem to be documented either way...except for the 'exclude_empty'
argument of testmod. If testmod throws an error when there are no docstrings
instead of returning a 0
Chris Jerdonek added the comment:
The problem seems to be restricted only to DocTestSuite. testmod and
DocTestFinder both seem to work fine. DocTestSuite calls DocTestFinder but not
the other way around: nothing calls DocTestSuite.
If in certain versions we do not treat raising the
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +asvetlov
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
___
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
versions: +Python 3.3
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
___
Chris Jerdonek chris.jerdo...@gmail.com added the comment:
I have attached a patch with tests.
--
keywords: +easy, patch
stage: - patch review
Added file: http://bugs.python.org/file26269/issue-14649-1.patch
___
Python tracker rep...@bugs.python.org
Changes by Chris Jerdonek chris.jerdo...@gmail.com:
--
nosy: +r.david.murray
___
Python tracker rep...@bugs.python.org
http://bugs.python.org/issue14649
___
___
New submission from Chris Jerdonek chris.jerdo...@gmail.com:
When invoking doctest.DocTestSuite's constructor with a module that has no
docstrings, doctest raises the following exception:
...
File
/opt/local/Library/Frameworks/Python.framework/Versions/3.2/lib/python3.2/doctest.py,
line
31 matches
Mail list logo
