aboutsummaryrefslogtreecommitdiffstats
path: root/markdown/__init__.py
Commit message (Collapse)AuthorAgeFilesLines
* Marked a bunch of lines as 'no cover'. Coverage at 91%Waylan Limberg2014-07-111-2/+2
|
* Support extensions as modules.Waylan Limberg2014-05-231-1/+1
| | | | | | | | | | Fixes #300. When a python module (.../__init__.py) is imported by `__import__` and the `from_list` argument is a unicode string (as is returned by rpartition), then an error is raised in Python 2.7. Force conversion to default string type (byte in 2.7 and unicode in 3) to avoid the error. For a full explaination, see issue [300](https://github.com/waylan/Python-Markdown/issues/300).
* Address various depreciated APIs in PythonWaylan Limberg2014-01-081-1/+1
| | | | | This mostly revolves around old APIs for ElementTree, but includes a few others as well. Fixes #254. Thanks for the report.
* Update __init__.pyMark Eichin2013-09-261-1/+1
| | | spelling.
* fix typoFND2013-09-041-1/+1
|
* Allow extensions to register serializersWaylan Limberg2013-08-071-1/+1
| | | | | | | | | Setting output_format must happen after extensions are loaded. Only in that way can an extension register a serializer so that it will then be available to be used with the output_format keyword. A test has been added to avoid this regression from happening again in the future. Fixes #238, partially reverses commit 41cc055 and provides a better fix for
* Remove some unused importsDmitry Shachnev2013-03-231-1/+0
|
* Future imports go after the docstringsAdam Dinwoodie2013-03-181-1/+1
| | | | | | | | | A `from __future__ import ...` statement must go after any docstrings; since putting them before the docstring means the docstring loses its magic and just becomes a string literal. That then causes a syntax error if there are further future statements after the false docstring. This fixes issue #203, using the patch provided by @Arfrever.
* Dict.keys() does not return a list in Python 3.Waylan Limberg2013-02-271-1/+1
|
* Now using universal code for Python 2 & 3.Waylan Limberg2013-02-271-24/+26
| | | | | | | | | | The most notable changes are the use of unicode_literals and absolute_imports. Actually, absolute_imports was the biggest deal as it gives us relative imports. For the first time extensions import markdown relative to themselves. This allows other packages to embed the markdown lib in a subdir of their project and still be able to use our extensions.
* Footnote ids contain dashes when outputing HTML5.Waylan Limberg2013-02-081-1/+1
| | | | | Previously they contained colons - and they still do for HTML4 and XHTML. Fixes #180.
* Updated docs to reflect extension loading best practices.Waylan Limberg2013-02-081-5/+0
| | | | Fixes #184. Also delted some commented out code I missed in previous commit.
* Moved whitespace normalization to a preprocessor.Waylan Limberg2013-02-081-4/+4
| | | | | | | | | | | | | | Fixes #150 - at least as much as I'm willing to. This allows whitespace normalization to be overridable by the extension API. Yes, I realize that most other processors will also proabably need to be overniriden to work with any differant whitespace normalization - but I'm okay with that. As pointed out in #150, some processors have the tab length hardcoded in regexes. I'm willing to accept a working patch that fixes that - and keeps the regexes easy to override in a subclass (the provded patch moved them inside the __init__ method - which is not so easy to override in a subclass)). However, that is about the only additional change I'm willing to consider for this issue.
* Cleaned up fixes for #183Waylan Limberg2013-02-081-0/+1
| | | | | | | | | My previous commit (d5a94c2) broke a few things badly. Unfortunately I failed to run the complete test suite and didn't catch it. A bad regex was crashing the test suite. Also cleaned up a few other odds and ends from previous work on #183. Still loosing a few random empty lines in code blocks though. I suspect this may also fix #188.
* Preserve whitespace in empty linesWaylan Limberg2013-02-071-1/+0
| | | | | | | | Partial fix for #183. By preserving tabs at the start of empty lines in code blocks, the parser will retain those empty lines. Still does not work consistantly if the tab is missing!? Not sure why. Also added tests.
* Preserve empty lines in code blocksWaylan Limberg2013-02-061-1/+1
| | | | | | Partial fix for #183. Some lines are still being lost. When the processors are run, one line is lost. When their calling code is comments out (completely skiped) a line is still lost if more than 3 exist in a row. Also need to add some tests for this.
* Upped version to 2.3.dev.Waylan Limberg2012-12-051-3/+1
| | | | | Also refactored the version info to force PEP 386 compliance and to avoid the need to change the version in both the source and setup.py
* Merge pull request #159 from mitya57/masterWaylan Limberg2012-11-091-1/+0
|\ | | | | Fixed pyflakes warnings
| * Fix all pyflakes unused-import/unused-variable warningsDmitry Shachnev2012-11-091-1/+0
| |
* | Updated fix for #158 for Python <2.7Waylan Limberg2012-11-081-1/+1
| | | | | | | | | | | | | | Apparently, the `errors` keyword to encode was added in Python 2.7. In previous versions, it was just a positional argument. This should now work in all support versions. Thanks to @Gamma3000 for assistance in working through this issue.
* | Fixed #158. Now properly encoding output to stdout.Waylan Limberg2012-11-071-8/+7
|/ | | | | | | | This is another try at this problem. The trick is geting code that works with both Python 2 and Python 3. I think this does it. The only improvment I can see now is to catch any errors and customize the error message to sugg that the user set the environment variable PYTHONIOENCODING to the desired encoding before calling the commandline script.
* Upped version to 2.2.1.Waylan Limberg2012-11-041-2/+2
|
* Misc typos.chri2012-08-281-1/+1
|
* Fixed encoding issues when writing to stdout.Waylan Limberg2012-08-231-2/+9
| | | | | | | | | | | | | | | | | In Python 2.x, if you write to stdout and stdout is piped (for example: `python -m markdown foo.txt | less`), then `sys.stdout.encoding` is `None` and an error is rasied. Commit 1132f9e20cd7a5d6be809651f1034c44c32dbc0e was an attempt to fix this, and it works in Python 2.x. However, it does not work in Python 3.x, which does not exhibit this problem. In fact, that fix actually breaks things in Python 3 whether the output is piped or not. Additionaly, in Python 2.x, the fix is not needed if the output is not being piped. As we do not have a version specific issue, but an issue with `sys.stdout.encoding`, we check for that to determine which way to go. This way, the "right thing" *should* happen every time.
* Improved `Markdown.set_output_format()`Waylan Limberg2012-08-091-4/+10
| | | | | | | | | | Specificaly, `self.output_format` is defined and contains a string of the output format used on the instance. This is more useful that an instance of the searializer when determining alternate behavior elsewhere in the parser. For example, see Issue #129. Also cleaned up the error when an invalid format is provided. We now re-raise the original error (with a custom message) rather than raising a new error.
* Fixed UnicodeEncodeError when output from markdown_py is piped into another ↵Alexander Artemenko2012-07-261-1/+2
| | | | | | | program. In this case text should be encoded into the output encoding explicitly, because sys.stdout.encoding is None, when piping data.
* Fixed #112 and cleaned up error reporting when loading extensions.Waylan Limberg2012-07-121-9/+13
|
* Upped version to 2.2.0-Final.2.2.0.finalWaylan Limberg2012-07-051-1/+1
|
* Fixed #105. Non-existant extensions fail with a warning only.Waylan Limberg2012-06-281-1/+1
|
* Updated version to 2.2.0.alpha.2.2.0.alphaWaylan Limberg2012-05-041-20/+20
|
* Fixed #82. 'enable_attributes' honors 'safe_mode'.Waylan Limberg2012-05-031-0/+4
| | | | | | | Note that you can still explicitly set 'enable_attributes' and that value will be honored regardless of 'safe_mode'. However if 'safe_mode' is on and 'enable_attributes' is not explicitly set, then 'enable_attributes' defaults to False.
* Typo fix in doc: s/extension-configs/extension_configs/Simon Sapin2012-03-191-1/+1
|
* Point to docs hosted with PyPI rather than Yuri's missing site.Waylan Limberg2012-03-071-1/+1
|
* Merge pull request #50 from nud/import-extensionsWaylan Limberg2012-01-241-6/+7
|\ | | | | Allow specifying the full module name for extensions.
| * Allow specifying the full module name for extensions.Steve Frécinaux2011-11-021-6/+7
| | | | | | | | | | | | | | | | | | | | | | | | Before this patch, it was possible to pass a list of extensions and parameters to use when instantiating a new Markdown instance, but it was not possible to give a full module name; the extension had to be a submodule in markdown.extensions. Now we allow giving a full module path, to make it easy to use custom extensions which are not bundled within the markdown package. The previous behaviour has been retained when there is no '.' in the extension name.
* | Release 2.1.1. A bugfix release.2.1.1.finalWaylan Limberg2012-01-221-3/+3
| |
* | It is spelled 'serializers' not 'searializers'.Waylan Limberg2012-01-201-1/+1
| |
* | Fixed a few typos in the doc strings. Thanks to Ivan Konev for the patch.Waylan Limberg2012-01-181-5/+5
| |
* | Fixed #61. stdin and stdout should work better in python 3.Waylan Limberg2011-12-281-15/+25
| | | | | | | | | | Apparently, in Python3 stdin and stdout take str (unicode) not bytes. This provides a solution that will work in both python 2 & 3.
* | Version 2.1.0-Final2.1.0.finalWaylan Limberg2011-11-241-2/+2
|/
* Release 2.1.0-Beta2.1.0.betaWaylan Limberg2011-10-101-2/+2
|
* Added greater-than as an escaped character. Apparently markdown.pl escapes ↵Waylan Limberg2011-08-271-1/+1
| | | | it even though it is not documented.
* Fixed #39. Refactored escaping so that it only escapes a predifined set of ↵Waylan Limberg2011-08-171-0/+3
| | | | chars (the set defined by JG in the syntax rules). All other backslashes are passed through unaltered by the parser. If extensions want to add to the escapable chars, they can append to the list at markdown.ESCAPED_CHARS.
* Set version to '2.1.0.alpha'.2.1.0.alphaWaylan Limberg2011-08-031-2/+2
|
* Added support for python's '-m' command line option. Do 'python -m markdown ↵Waylan Limberg2011-08-031-2/+0
| | | | [options] [args]'. I suspect will drop the command line script (markdown_py) when we drop support for Python 2.4 as this is easier to support.
* Markdown.convertFile now actually works with stdin and stdout. Previously ↵Waylan Limberg2011-08-031-3/+6
| | | | only the commandline script did.
* Fixed a Python 2.4 incompatability in last commit. 'encode' only accepted ↵Waylan Limberg2011-07-281-1/+1
| | | | positional arguments back then.
* All internal encoding of output now uses the 'xmlcharrefreplace' error ↵Waylan Limberg2011-07-281-3/+6
| | | | handler. Also added a note to the docs. Anyone doing their own encoding of output should be as well.
* Stripped out encoding/decoding in the searializers.Waylan Limberg2011-07-271-1/+1
| | | | | | | | | | | | | | | | | | | | | | | Those extra steps always bothered me as being unnecessary. Additionally, this should make conversion to Python 3 easier. The 2to3 tool wasn't converting the searializers properly and we were getting byte strings in the output. Previously, this wasn't a major problem because the default searializer was the xml searializer provided in the ElementTree standard lib. However, now that we are using our own xhtml searializer, it must work smoothly in all supported versions. As a side note, I believe the thought was that we needed to do the encoding to take advantage of the "xmlcharrefreplace" error handling. However, using the example in the python [docs](http://docs.python.org/howto/unicode.html#the-unicode-type): >>> u = unichr(40960) + u'abcd' + unichr(1972) >>> u.encode('utf-8', 'xmlcharrefreplace').decode('utf-8') == u True There's no point of using the "xmlcharrefreplace" error handling if we just convert back to the original Unicode anyway. Interestingly, the Python 3 standard lib is doing essentially what we are doing here, so I'm convinced this is the right way to go.
* also respect encoding when reading from a user-provided fileTravis Parker2011-06-251-1/+1
|