Skip to contents

A .qmd whose declared/inferred engine is Python (see code_lang()'s .qmd_lang()) cannot go through code_extract_r(): knitr::purl() only recovers ```{r} chunks, so a Python-engine document would purl to nothing. This is the .qmd analogue of code_extract_r() for that case — concatenating the body of every ```{python} fence in document order, the same "recover a checkable code file" idea code_extract_py() applies to a .ipynb's code cells (chunk boundaries are preserved as a blank line so line counts stay meaningful).

Usage

code_extract_qmd_py(file_path = NULL, save_path = NULL, text = NULL)

Arguments

file_path

a path to a .qmd file

save_path

if NULL, returns a text vector, else a path to save to

text

alternative to file_path, pass text directly

Value

a character vector of Python source lines (empty when the document has no Python chunks)

Details

Unlike code_extract_r(), this is a plain text/regex scan, not a real Pandoc/Quarto parse: a fence marker appearing inside a string literal or a displayed (non-executable) code block written with four backticks around a literal ```{python} would be misread as a real chunk. This mirrors the fence-based approach already used elsewhere in the module (e.g. code_parse_r()'s own ^---\\s*$ front-matter check) rather than introducing a new parsing dependency for a single edge case.

Examples

qmd <- c("---", "title: Demo", "---", "Some text.", "```{python}",
         "x = [1, 2, 3]", "print(sum(x))", "```")
code_extract_qmd_py(text = qmd)
#> [1] "x = [1, 2, 3]" "print(sum(x))" ""