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 here.

• Create a new Organization on GitHub for "Python-Markdown" and fork waylan/Python-Markdown to Python-Markdown/markdown. All work on 3.0 will happen at this new repository. The 2.x series will remain at waylan/Python-Markdown, which will be in "maintenance mode" and only receive bug fixes (2.6.x) going forward.

• 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_emphasis (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".