Closed mmcky closed 6 years ago
Thanks @jlperla for the following:
@arnavs You can take a shot at this. The basic idea is that we would introduce a :class: test as a parallel to :class: solution`
:class: test
The beautiful thing now is that we can almost use identical code wherever the word solution is used in the https://github.com/QuantEcon/sphinxcontrib-jupyter/pull/72/files
solution
In partiular,
sphinxcontrib/jupyter/__init__.py
app.add_config_value("jupyter_drop_tests", False, "jupyter")
sphinxcontrib/jupyter/writers/translate_code.py
test
self.test= _parse_class["test"]
Then in the visitor if we are in a test and the option is set to drop them, we just pass and don't output the code. i.e.
pass
if self.solution and self.jupyter_drop_solutions: pass
tests/conf.py
jupyter_drop_tests = True
jupyter_drop_solutions = False
You can ask @mmcky but I think a lot of the other stuff in the PR also does something with output blocks, which I believe is orthogonal?
@mmcky I think we can close this now.
thanks @arnavs
Thanks @jlperla for the following:
@arnavs You can take a shot at this. The basic idea is that we would introduce a
:class: test
as a parallel to :class: solution`The beautiful thing now is that we can almost use identical code wherever the word
solution
is used in the https://github.com/QuantEcon/sphinxcontrib-jupyter/pull/72/filesIn partiular,
sphinxcontrib/jupyter/__init__.py
sphinxcontrib/jupyter/writers/translate_code.py
we need to parse thetest
class and add a flag in the visitorThen in the visitor if we are in a test and the option is set to drop them, we just
pass
and don't output the code. i.e.tests/conf.py
we set the option withjupyter_drop_tests = True
orjupyter_drop_solutions = False
You can ask @mmcky but I think a lot of the other stuff in the PR also does something with output blocks, which I believe is orthogonal?