New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
doctest directive examples in library/doctest.html lack the flags #57156
Comments
The docs for the doctest module contains examples that use doctest flags to control behavior, but the HTML version does not contain the flags, making the examples useless. I don’t know if this is a bug with the HTML builder or something we can fix in markup. |
Ezio prompted me to give precise examples, and I can’t find any in the docs online. Maybe it was only a local build with certain options that caused this problem, I’ll reopen if I find out. |
Hehe... Sphinx makes a point of *removing* doctest flags, to enable doctesting of code snippets without distracting the reader with the test-internal flags. I think it's because you used a newer version locally. |
Concrete examples can be seen in the section http://docs.python.org/library/doctest.html#option-flags-and-directives For instance at http://docs.python.org/library/doctest.html#doctest.IGNORE_EXCEPTION_DETAIL The doctest flags present in the sources in http://docs.python.org/_sources/library/doctest.txt are all stripped. |
Thank you. I think it’s clear that for the docs of the doctest flags we need to display snippets with the flags. |
As far as I can see, Sphinx has a global setting for trim_doctest_flags but lacks the possibility of locally disabling the trimming. A quick workaround would be to have the following sphinx extension added: class ProxyLexer(object):
def __init__(self, underlying):
self.__underlying = underlying
def __getattr__(self, attr):
return getattr(self.__underlying, attr)
def setup(app):
from sphinx.highlighting import lexers
if lexers is not None:
lexers['pycon-literal'] = ProxyLexer(lexers['pycon'])
lexers['pycon3-literal'] = ProxyLexer(lexers['pycon3']) That would allow blocks marked as .. code-block:: pycon-literal or preceded by .. highlight:: pycon-literal to escape the trimming of doctest flags. If that's of any interest I can submit a patch. |
Is there a way to add a :keep-doctest-flags: options to literal blocks? |
Ezio, the patch I attached goes into that direction, by adding a ":trim-doctest-flags: disable" option to the code blocks. I thought I had a good reason for having the option worded as ":trim-doctest-flags: disable" instead of ":keep-doctest-flags:", now I'm not so sure. Note: the patch is against the 2.7 branch. |
The directives should normally be stripped, but not when they are intentionally given to teach their existence, syntax, and use, as in the doctest doc on directives. I opened (and closed -- am trying to anyway) a duplicate, bpo-14865. The problem of directive stripping started in 3.2.0 and subsequently 2.7.3 (after 2.7.2 in June 2011) and contiues in 3.3.0. Sandro Tosi noted [1] https://bitbucket.org/birkenfeld/sphinx/issue/169/strip-doctest-csomments-in-rendered-output My question is whether the added true-by-default In any case, this is a nasty regression in the docs and should be fixed somehow before the next releases. It makes the examples actively confusing. |
I discovered this today as well while reading the doctest documentation. One thing that I never noticed before (and that doesn't seem to be reflected in the comments above) is that many of the code snippet rectangles in the doctest documentation have a small rectangle in the upper-right corner with the text ">>>". If you click on one of these small rectangles, most of the text inside the code snippet rectangle disappears. I haven't confirmed this, but I suspect that it is the code snippets with a doctest directive that have this clickable corner. Is this a feature? What is it for? :) |
The >>> is added to every example that contains an interactive session to hide the '>>>' and '...' prompts and the output and make the code copy/pastable, and it's not specific to doctests. |
New changeset 662fb4bd5f84 by Nick Coghlan in branch '2.7': |
New changeset 679b3e3aadae by Nick Coghlan in branch '3.3': |
Since the status quo is thoroughly confusing for readers, I added an explicit note before the affected examples. That note should be removed once the rendering problem is fixed. (The note is there on trunk as well, I just forgot to include the issue number in the merge commit) |
I thought of an easy work-around we can use after looking at the changeset Terry referenced above:
At the expense of pretty color highlighting, we can enable Pygments' TextLexer for the affected examples (aka "null" lexer). For example-- .. code-block:: text >>> raise CustomError('message') #doctest: +IGNORE_EXCEPTION_DETAIL
Traceback (most recent call last):
CustomError: message I confirmed locally that this works. I realized this might work because the Sphinx changeset referenced above has this logic: # trim doctest options if wanted
if isinstance(lexer, PythonConsoleLexer) and self.trim_doctest_flags: |
New changeset 18d927fb8671 by Nick Coghlan in branch '2.7': |
New changeset d93a59a0a984 by Nick Coghlan in branch '3.3': New changeset 26200f535296 by Nick Coghlan in branch 'default': |
Adopted Chris's workaround for now. I kept a reworded version of the preceding note (with the link to this bug), so readers know that the lack of syntax highlighting is intended-but-not-desired. |
Thanks, Nick. It looks like there are a few more though? I'm counting four more in default (search for "doctest:"): three IGNORE_EXCEPTION_DETAIL and one ELLIPSIS. |
I only changed the ones that were specifically in the section explaining doctest directives. There are probably others, but it didn't seem necessary to change them and lose the syntax highlighting at this point. |
http://docs.python.org/py3k/library/doctest.html#option-flags-and-directives has the improved version. Thanks. Here, the complete example text is more important than the hi-lites. |
Ah, I see the other examples Chris is talking about now. Yes, the workaround should be applied in those cases as well. |
New changeset 00555659253d by Chris Jerdonek in branch '3.3': New changeset 467c9f663b77 by Chris Jerdonek in branch 'default': New changeset 15bfa778ec21 by Chris Jerdonek in branch '2.7': |
I added the workaround to the last remaining example. Nick was right before in that three of the four examples I mentioned above were in the part about "option flags" rather than in the part about "directives". I made those two parts into their own sections for added clarity. |
New changeset 9057da41cf0b by Georg Brandl in branch '3.2': New changeset 1202c1449d83 by Georg Brandl in branch '3.3': |
New changeset ffe9f644d5af by Georg Brandl in branch '2.7': |
Thanks, Georg. Can this new directive be applied to individual code blocks though (or be modified to do so)? After a closer review (as mentioned in my comment above), it seems that the doctest directives should only be displayed in the code snippets that are illustrating the use of doctest directives (as opposed to, say, the snippets that are illustrating doctest options without using directives). |
I don't see any blocks in doctest.rst where the directives should be stripped, so it's enough to do it per-file. |
Like these that discuss the behavior of the doctest.IGNORE_EXCEPTION_DETAIL option (but before doctest directives have been introduced): http://hg.python.org/cpython/file/0d6910bef979/Doc/library/doctest.rst#l543 The key is that you can have options take effect without using directives, so it would be good if people can see examples like that. |
Georg suggested removing the doctest directives from the examples I mentioned. As currently written, they don't help them pass if doctest were run on the .rst file. That sounds fine to me for now. |
New changeset 705a70b0fff4 by Chris Jerdonek in branch '3.3': New changeset 9475fc82768e by Chris Jerdonek in branch 'default': New changeset 8704f9e7ad7c by Chris Jerdonek in branch '2.7': |
This seems to look good now. Can this be closed, or is there something else that needed to be done as well? |
I looked at |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: