python-markdown-discuss

[Python-markdown-discuss] lxml.etree? (trying to do something with treeprocessor)

[Mark E. <ei...@gm...>]

I'd like to write a treeprocessor that takes the <h2> elements and
stuffs <a name="..."> anchors before them (with the anchorname derived
from the h2 text.)  markdown.etree does give me findall... but the
Elements I get back don't appear to have any sibling operations that
would let me do that.

First question is of course "is there a better way to do that"...
second is, does it make sense to consider lxml.etree another candidate
for etree_loader.importETree?  (That would at least give me
addprevious which does exactly what I'm looking for...)

I did try
   import lxml.etree
   markdown.etree = lxml.etree
(right after the "import markdown" itself) which got a couple of
FutureWarnings and a fatal complaint about null bytes in strings, so
it doesn't Just Work...

--
_Mark_ <ei...@th...> <ei...@gm...>

Re: [Python-markdown-discuss] lxml.etree? (trying to do something with treeprocessor)

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

> from the h2 text.)  markdown.etree does give me findall... but the
> Elements I get back don't appear to have any sibling operations that
> would let me do that.

I can't remember right now, but it's possible that ElementTree
interface just doesn't provide that method.

> second is, does it make sense to consider lxml.etree another candidate
> for etree_loader.importETree?  (That would at least give me
> addprevious which does exactly what I'm looking for...)

We did at one point, but found lxml's implementation of ETree to have
a lot of quirks along the lines you mentioned below. (You can search
the list archives for "lxml" to find those discussions.) It may be
worth looking at this again and considering if we can fix those issues
on our end, but at the time, if I remember correctly, it didn't seem
worth it.

Have you considered just traversing the tree top-down once and
inserting all the extra tags that you need?

- yuri

Re: [Python-markdown-discuss] lxml.etree? (trying to do something with treeprocessor)

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

On Fri, Aug 21, 2009 at 12:09 AM, Mark Eichin<ei...@gm...> wrote:
> I'd like to write a treeprocessor that takes the <h2> elements and
> stuffs <a name="..."> anchors before them (with the anchorname derived
> from the h2 text.)

Why not just set the id on the h2 tag? Like this: `<h2 id="...">`. It
accomplishes the same thing and is actually considered the correct way
to do it today. In fact, the HeaderId extension [1] included with
Markdown already does this.

Regarding the issues with ElementTree, yes, unfortunately, ET elements
have no reference to their parent, thus no knowledge of their
siblings, which, needless to say is very annoying. Probably my biggest
gripe. But Yuri's recollection is correct. We initially tried to offer
lxml as an option but there were just to many differences to make it
work right with both. I believe lxml's poor Unicode support was a
problem as well. As Yuri mentioned, search the list archives for more.
Of course, if we could get it working, I would gladly do so for both
the performance increase and references to parent elements.

[1]: http://www.freewisdom.org/projects/python-markdown/HeaderId

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] lxml.etree? (trying to do something with treeprocessor)

[Mark E. <ei...@gm...>]

On Fri, Aug 21, 2009 at 9:28 AM, Waylan Limberg<wa...@gm...> wrote:
> On Fri, Aug 21, 2009 at 12:09 AM, Mark Eichin<ei...@gm...> wrote:
>> I'd like to write a treeprocessor that takes the <h2> elements and
>> stuffs <a name="..."> anchors before them (with the anchorname derived
>> from the h2 text.)
>
> Why not just set the id on the h2 tag? Like this: `<h2 id="...">`. It
> accomplishes the same thing and is actually considered the correct way
> to do it today. In fact, the HeaderId extension [1] included with
> Markdown already does this.

... because it never occurred to me that there'd be "new" syntax for
that... sure enough,
http://www.w3.org/TR/html401/struct/links.html#h-12.1.1 (amusingly,
that document *itself* still uses <a name="..."> but it puts that
inside the <h3> so it avoids the problem from a different direction.)

(4.01 was published in 1999, so I suppose I can't really call that
"new", can I :-)

> Regarding the issues with ElementTree, yes, unfortunately, ET elements
> have no reference to their parent, thus no knowledge of their
> siblings, which, needless to say is very annoying. Probably my biggest
> gripe. But Yuri's recollection is correct. We initially tried to offer
> lxml as an option but there were just to many differences to make it
> work right with both. I believe lxml's poor Unicode support was a
> problem as well. As Yuri mentioned, search the list archives for more.
> Of course, if we could get it working, I would gladly do so for both
> the performance increase and references to parent elements.

Got it, thanks.

> [1]: http://www.freewisdom.org/projects/python-markdown/HeaderId
>
> --
> ----
> \X/ /-\ `/ |_ /-\ |\|
> Waylan Limberg
>



-- 
_Mark_ <ei...@th...> <ei...@gm...>