Re: [Python-markdown-discuss] future changes for markdown

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

> This makes sense. Should postprocessors be done in this fashion? That
> requires a DomPostprocessor and TextPostprocessor. Since they all
> roughly have the same syntax, we could just collapse them into
> TextProcessor, LineProcessor, and DomProcessor.

Interesting.  Note thought that DomProcessor is only makes sense in
the end when there is a dom script.  Also, mixing DomProcessors and
TextProcessors would probably carry a lot more of a performance
penalty, plus parsing the output into NanoDom would create tons of
additional problems.

> Why use this instead of just doing "isinstance(processor,
> TextProcessor)" and etc?

That's probably better.  I just wrote the first thing that came to mind.

> Or even better, just call a "process_lines",
> "process_text", or "process_dom"? With these functions, we don't even
> have to complicate the core markdown pipeline. Just have:
>
> class LineProcessor(TextProcessor):
>   def process_text(self, text):
>     return '\n'.join(self.process_lines(text.split('\n')))

I was just trying to avoid converting text back and forth.

> On a side note, what version of python are you targeting? It'd be nice
> if it were 2.3 and above. We could replace some amount of code with some
> standard libraries, such as logging.

I've been trying to keep it running with earlier versions too, but
maybe it's time to abandon them.  What do others think?

> Also, are you familiar with setuptools? It's a pretty close to drop-in
> replacement for distutils, and it has some nice things like plugin
> support. I've hacked up support for it in markdown, but it's not really
> in a great condition yet. Would this be interesting for you?

Yes.  But it's low priority.  Which is to say, if someone wanted to
offer help with this, I would appreciate it, but I don't have the time
at the moment to dive into it.

 - yuri

-- 
http://www.freewisdom.org/