From: Erick T. <ida...@us...> - 2007-05-18 08:38:49
|
> We can add two subclasses of Preprocessor: TextPreprocessor and > LinePreprocessor. (For now LinePreprocessor would behave as > Preprocessor but we can deprecate it later). 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. > Each will have a > get_input_type() method which would return "lines" or "text" which > will signify what input it expects. Either would be allowed to return > a list of lines _or_ text. Markdown will check type and do the > conversion if adjacent preprocessors want different formats. Why use this instead of just doing "isinstance(processor, TextProcessor)" and etc? 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'))) 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. 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? -e |