Re: [Python-markdown-discuss] GSoC plan

[Artem <ne...@gm...>]

Yuri Takhteyev  wrote:
> It's ok to break backwards compatibility with extensions, if this buys
> us enough.  Similarly, we can think of dropping Python 2.3 support -
> again if this really buys us something big.  In particular, as far as
> the tree representation goes, we can consider a couple of things, in
> particular:
>
> 1. Stick with NanoDOM, fixing the problems you mentioned
> 2. Switch to ElementTree
>
> Let's discuss those options.  (Or other.)
>   
I thought about ElementTree, but there is a problem with entities 
escaping and I I didn't find any beautiful solution yet.
> (Artem: can you make a page for this project on the wiki, to keep
> track of the questions and the decisions, and then start separate
> threads for each question, though probably not all at the same time?)
>
>   
Sure. 
Here it is: http://www.freewisdom.org/projects/python-markdown/GSoC2008
> In other words, my suggestion is that the first round of parsing
> should turn the document into a tree of blocks, where nodes in the
> tree represent individual simple paragraphs, list items, block quotes,
> code segments, block level HTML elements, etc.  The client will then
> ideally be able to get this tree back if they want.  The second round
> of parsing would then simply go through this tree and run a different
> set of regular expressions on each node depending on the type of the
> node.
>
>   
Thanks for the suggestion. Do you mean that the first round of parsing 
should be without regexps?
> Yes, let's first do inline patterns, and see what this gives us.
> Another thing that could be done is avoiding excessive recursion in
> block parsing.  But let's do one thing at a time
Ok.
> Sounds good, but don't get too sidetracked on this.  Also, we need to
> make sure there is someone on Crunchy project who is actually
> interested in this and will make use of it.
>
>   
I think we should contact with André Roberge.
>> - Test suite extension
>>     
>
> Yes, in fact, I would consider doing this _first_.  I.e., it would be
> good to put together a unified test suite that combines all of our and
> Trent's tests and gives us a better idea of where the two
> implementations stand relative to each other.
>
> BTW, I would urge you to make sure that your modified version of
> python markdown passes all of our tests (and an increasing number of
> Trent's) at least once a week.  Let's avoid the "Version 2" problem.
>
>   
Got it.
>> - Some additional documentation, maybe adding more examples about
>> writing extension modules.
>>     
>
> Let's put this off till later.  If we'll be making serious changes, it
> makes more sense to work on the documentation after the work is done.
> But it would be good if you could at least document any changes that
> you end up making before the end of the summer.
>   
Ok.