Re: [Python-markdown-discuss] refactoring and treap integration

[Yuri T. <qar...@gm...>]

> Well, maybe not so cool. By making all (most) of the methods truly
> private it makes moneypatching more difficult. I realize it's not that
> hard to use a subclass rather than monkeypatch, but what happens when
> two extensions each create their own subclass changing a different
> method? With monkeypatches, we just used the same instance and all was
> good.

They don't have to stay private.  I decided to start by making them
private in order to expose any questionable dependencies that we may
have.  We can then think of whether there are a few more methods that
may be worth exposing.

>    md.parser._MarkdownParser__processCodeBlock = __hiliteCodeBlock

I think there is an entirely different (and better) way to do this
now.  Use the standard MarkdownParser, then write a postprocessor to
modify the eTree.  At the moment, it appears that we don't offer an
option of modifying the tree before the patterns are run, but we
should.  I.e., our pipeline should be:

1. text pre-processors (text-in, text-out) - tempated to drop this
2. line pre-processors (line list in, line list out)
3. MarkdownParser.parseDocument() - substitute your own if you want
4. pre-pattern post-processors (modify the tree before any patterns are run)
5. InlineProcessor.applyInlinePatterns()
6. etree postprocessors (modify eTree)
7. serialization of the etree into a string
8. text postprocessors (text-in, text-out)

My generic recommendation now would be that extension writers first
look into whether they can do what they want to do by adding
post-processors at steps 4, 6 or 8, or by adding patterns.

- yuri

-- 
http://sputnik.freewisdom.org/