Inputing also ".rst" files

If we ever want to also input “.rst” files, it’s really easy to read them in, and convert them to .py files.

I just came across some code lying on my disk since a while (probably copy-pasted from Internet):

from docutils.core import publish_doctree

doctree = publish_doctree(open('input.rst').read())

def is_code_block(node):
    return (node.tagname == 'literal_block')

code_blocks = doctree.traverse(condition=is_code_block)
source_code = [block.astext() for block in code_blocks]

with open('output.py', 'w') as f:
    f.write('\n######################\n\n'.join(source_code[2:]))

So we should keep in mind that it’s probably a low cost feature that might make users happy.

[larsoner]

Yes we already do it – I’m saying that this might be a problem / conflict if we implement a “run all RST” feature

[bdice]

@larsoner Excellent response! This helped explain a lot of the parts that I didn’t know. I am interested in pursuing this concept further, especially if there is interest from other sphinx-gallery users. I’m probably going to work on enabling sphinx-gallery for a project first, so I can get more familiar with its usage and features.

@lucyleeow Good question. I use standard Sphinx-style, NumPy-style, and Google-style docstrings in different projects, so I would want to support all of them, but I think that should be possible. I would guess that there’s a layer/stage of the process at which all example code snippets are handled the same way and could be detected/executed without needing to specialize for different formats/tools, but I am not super familiar with the internals of these packages.