3.0 Roadmap

This is the plan to work towards a 3.0 release. This is a "living document" and will be edited over time. You can find a version with a slightly different format which includes some explanations in #391.

• All work on 3.0 will happen in the md3 branch. The 2.x series will remain in the master branch, which will be in "maintenance mode" and only receive bug fixes (2.6.x) going forward.All work is now happening on the master branch. ANyting on the md3 branch which we are keeping has been moved over to master.

• Create a new Organization on GitHub for "Python-Markdown" and move waylan/Python-Markdown to Python-Markdown/markdown.

• Each built-in extension will be broken out into a separate package at Python-Markdown/<package name> and, upon release, uploaded to PyPI as a separate package. Users can do pip install extensionname for each extension they want.

• All of the existing deprecation paths would be fast-tracked. The changes would hit hard with no warnings in 3.0.

• InlinePatterns => inlineprocessors (which match all other types)

• Some keywords on markdown.Markdown might be moved to extensions.

  • enable_attributes => legacy_attrs
  • smart_emphasis => legacy_em (also combine the existing "smart_strong" ext)
  • lazy_ol => sane_lists

• Some processor types currently use self.md and others self.markdown to refer to the Markdown instance. This will be normalized to self.md.

• Remove the md_globals keyword from the extension API. Years ago, state and/or settings were stored in module level globals. We no longer use globals (aside from a few things in markdown.utils); everything is now stored on the class instance.

• The changes to the various blockprocessors described in #53 will be implemented (the test method of blockproccesors will be dropped).

• An effort should be made to improve the inline handling code. A better solution should be explored than the current placeholder madness to allow proper nesting. Most likely, such a solution would also address the issue raised in #161. Perhaps remove the requirement that all inline regex patterns be wrapped by (.*) both before and after the supplied regex before compiling.

• Refactor testing framework to be usable by third party extensions

• Load string based extensions via entry points (I really like this)

• Use Setuptools (for all features of the setup script except build_docs)

• Explore using a proper HTML parser for handling raw HTML.

• A third party documentation generator will mostly likely be adopted (see #369).

• Explore alternatives to our homegrown OrderedDict (the standard lib one won't work as it only allows adding items to the end).

• Simplify "output_formats" to "html" and "xhtml".