Chris Sewell

Improve SmartQuote performance

Again you haven’t supplied any reference to support your claims. you have not given a single reason why not GitLab You wouldn’t be able to have integrated referencing (in issues and PRs) between docutils and sphinx, readthedocs, myst, and the majority of the python ecosystem that are on GitHub. Also first-class integration with VS Code, the most used development tool,... Anyhow I’m not going to continue a flame war. I just wanted to make sure that your views wasn’t the only one represented here....

GitHub is often blocked by companies / agencies because of the sites ties to China GitHub is owned by Microsoft, so I’m a bit confused by your insertion it has ties to China. A company could choose to block any site at any time, so I don’t think this should be a consideration. Also https://github.com/python https://github.com/python itself is on GitHub and most core Python tools, so if your company does block GitHub, you are going to find it difficult to do any Python development. when the suggested...

sounds good Consider moving to a new settings-spec format based on ordered dicts Minor note, since python 3.7 standard dicts are guaranteed to be ordered: https://docs.python.org/3/whatsnew/3.7.html

Well thank you for your help Clement! Agreed. So we may close the ticket as "open-fixed"? Sounds good to me thanks, and don't hesitate to get in touch for any other related issues :)

Firstly, definitely +1 in general for "inline" type annotations. In my experienece, type annotations are often most useful in private / internal code -- the public API is often well specified That's an interesting take 😬 As noted in the original post, the major use-case of these type annotations are for third-party extension development, e.g. to allow for programmatic (mypy) type checking against docutils usage. Third-party extensions should "only" care about the public API

That great cheers, indeed the aliases are the main thing here: I would prefer docutils itself did not override the myst_parser.docutils_.Parser (as it does for the recommonmark parser) and instead any required changes/improvements were implemented directly in myst-parser. Obviously, I will leave it up to you guys, as to any testing you want to include directly in docutils. For the "markdown"/"commonmark" alias, I would certainly be for it using myst-parser, but note that this would currently be equivalent...

As an aside, I am also working on propagating this first-class docutis support to https://github.com/executablebooks/MyST-NB, so you can do e.g. mystnb-docutils-pseudoxml --report="info" --nb-execution-mode=cache tests/notebooks/basic_unrun.ipynb, but more on that at a later date :)