Re: [Python-markdown-discuss] GSoC progress

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

> On 3-Jul-08, at 5:39 PM, Artem Yunusov wrote:
>> As far as I understand all the HTML from input replacing by
>> placeholders, and then inserting back only after serialization. So, it
>> won't be a problem in this case.

Yes, Artem is right, we are now not attempting to parse HTML submitted
by the user, we just pass it through.  This is what most (all?)
markdown implementations do.  This also means that if the user
supplies bad HTML (or HTML that is not XHTML), then they will get back
what they gave us.  Garbage in, garbage out.

The consensus on the markdown list seems to have been that policing
HTML submitted by the user (which would include looking out for XSS
attacks) should be left to the client, who should filter the output of
markdown.

> For some reason I was under the impression that  the "instant html/
> xhtml output option" meant "html which includes html in the input".

Again, I think it would be nice to give the user an option for
outputting HTML4 version of the tags that we add.  User's HTML is
their business, however  Clients who want to convert markdown text
with pieces of XHTML to HTML4 should use markdown to generate XHMLT
(with their pieces of XHTML embedded verbatim) and then find a way to
convert this to HTML4.  Or they can convert their chunks of XHTML to
HTML4 first.)

That said, if we offer the client an option of just getting an
ElementTree back from markdown (which they can then manipulate to
their heart's content), then this option would surely be more
attractive if we could also parse their (X)HTML.

Now, onto the question of performance.  I would like to continue
supporting python 2.3 and python 2.4, but I think we can compromise
here.  If ElementTree is easy to install for python 2.3 and 2.4 and if
our script can fallback gracefully from cElementTree to ElementTree
then this seems like a reasonable option.  I am ok with suffering a
(small) reduction in performance on earlier versions of python if this
will gain performance on python2.5.  (As I mentioned before, I would
prefer to offer 2.3 support as long as frameworks like django do so.)

Either way, Artem, make a branch from what you have now, to make sure
that you can continue pushing relevant bug fixes into the
pre-ElementTree version.  After that, perhaps the thing to do is to
try ElementTree to see what it gives us in terms of performance (for
python2.5), without worrying too much about the tests.  If it's a
substantial boost, you can then work on making sure that the output is
actually the same.

 - yuri

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