| 1 |
Python-Markdown 2.0 Release Notes |
| 2 |
================================= |
| 3 |
|
| 4 |
We are happy to release Python-Markdown 2.0, which has been over a year in the |
| 5 |
making. We have rewritten significant portions of the code, dramatically |
| 6 |
extending the extension API, increased performance, and added numerous |
| 7 |
extensions to the distribution (including an extension that mimics PHP Markdown |
| 8 |
Extra), all while maintaining backward compatibility with the end user API in |
| 9 |
version 1.7. |
| 10 |
|
| 11 |
Python-Markdown supports Python versions 2.3, 2.4, 2.5, and 2.6. We've even |
| 12 |
released a version converted to Python 3.0! |
| 13 |
|
| 14 |
Backwards-incompatible Changes |
| 15 |
------------------------------ |
| 16 |
|
| 17 |
While Python-Markdown has experienced numerous internal changes, those changes |
| 18 |
should only affect extension authors. If you have not written your own |
| 19 |
extensions, then you should not need to make any changes to your code. |
| 20 |
However, you may want to ensure that any third party extensions you are using |
| 21 |
are compatible with the new API. |
| 22 |
|
| 23 |
The new extension API is fully documented in [[writing_extensions]]. Below is a |
| 24 |
summary of the significant changes: |
| 25 |
|
| 26 |
* The old home-grown NanoDOM has been replaced with ElementTree. Therefore all |
| 27 |
extensions must use ElementTree rather than the old NanoDOM. |
| 28 |
* The various processors and patterns are now stored with OrderedDicts rather |
| 29 |
than lists. Any code adding processors and/or patterns into Python-Markdown |
| 30 |
will need to be adjusted to use the new API using OrderedDicts. |
| 31 |
* The various types of processors available have been either combined, added, |
| 32 |
or removed. Ensure that your processors match the currently supported types. |
| 33 |
|
| 34 |
What's New in Python-Markdown 2.0 |
| 35 |
--------------------------------- |
| 36 |
|
| 37 |
Thanks to the work of Artem Yunusov as part of GSoC 2008, Python-Markdown uses |
| 38 |
ElementTree internally to build the (X)HTML document from markdown source text. |
| 39 |
This has resolved various issues with the older home-grown NanoDOM and made |
| 40 |
notable increases in performance. |
| 41 |
|
| 42 |
Artem also refactored the Inline Patterns to better support nested patterns |
| 43 |
which has resolved many inconsistencies in Python-Markdown's parsing of the |
| 44 |
markdown syntax. |
| 45 |
|
| 46 |
The core parser had been completely rewritten, increasing performance and, for |
| 47 |
the first time, making it possible to override/add/change the way block level |
| 48 |
content is parsed. |
| 49 |
|
| 50 |
Python-Markdown now parses markdown source text more closely to the other |
| 51 |
popular implementations (Perl, PHP, etc.) than it ever has before. With the |
| 52 |
exception of a few minor insignificant differences, any difference should be |
| 53 |
considered a bug, rather than a limitation of the parser. |
| 54 |
|
| 55 |
The option to return HTML4 output as apposed to XHTML has been added. In |
| 56 |
addition, extensions should be able to easily add additional output formats. |
| 57 |
|
| 58 |
As part of implementing markdown in the Dr. Project project (a Trac fork), among |
| 59 |
other things, David Wolever refactored the "extension" keyword so that it |
| 60 |
accepts either the extension names as strings or instances of extensions. This |
| 61 |
makes it possible to include multiple extensions in a single module. |
| 62 |
|
| 63 |
Numerous extensions are included in the distribution by default. See |
| 64 |
[[available_extensions]] for a complete list. |
| 65 |
|
| 66 |
See the [[change_log]] for a full list of changes. |
