Re: [Python-markdown-discuss] Announcing Definition List Extension - call for testing

[Waylan L. <wa...@gm...>]

On Mon, Nov 10, 2008 at 4:37 AM, Yuri Takhteyev <qar...@gm...> wrote:
>>> The main markdown parser marked some methods with __'s... which is
>>> supposed to be the indicator that the method is private.  So it's a
>>> little bit disturbing that DefListParser is drilling into those
>>> internals.  Perhaps it's indicative that those methods should be
>>> exposed more, or that we need an extra hook point into the code?
>>
>> That's a valid point and one I've thought about as well.
>> Unfortunately, I don't have a good answer yet. Part of my motivation
>> in doing this extension was to raise these questions and see how
>> things go.
>
> What worries me more, actually, is the fact that the extension ends up
> duplicating much of the code in markdown.py  and then substitutes the
> parser.  Substituting the parser should be a no-no for extensions.
> (Note that if several extensions do this, then one will break
> another.)

I am very aware of this problem and don't particularly like it myself.
However, the nature of the definition list syntax makes it much easier
to do within the core than elsewhere. Currently, the only way to add a
new block type to the core is to override the parseChunk method and
add a call to your code within the various if statements in that
method. And then the paragraph code is not really generic enough to
the point that many other block types deffer to it to do the right
thing.

> Can you explain what changes you are trying to make to the parser?
> Perhaps we can find a way to make the parser a little more flexible,
> so that def_list extension will just need to add a hander to it,
> rather than having to swap in a new parser.

Actually, over the last few days I've put together a completely new
core processor which works very differently. Like the other plugable
parts of markdown, it loops through a list (OrderedDict actually) of
BlockProcessors and parses the source text one block at a time. An
extension could easily add, remove, replace individual pieces of the
parser without the problems we currently have. Additionally, it runs
faster (by about 1 second for 1000 iterations) than the current code
and uses less recursion. It also overcomes some of the parsing
differances unique to the python implementation (i.e.: <p>s in lists
match pl and php behavior) although an extension could easily provide
the current behavior instead.

It's not quite ready yet, but in the next few days I'll post something
here for others to review.

-- 
----
Waylan Limberg
wa...@gm...