From: Erick T. <ida...@us...> - 2007-05-25 16:32:54
|
Yuri Takhteyev wrote: >> 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. Thats true. I do personally like the different phases of processors. I think makes sense to not mix them. I thought thats just what you wanted. >> 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. You can still use duck typing without doing all this string conversion all the time. Also, since I've only found 5 or 6 markdown plugins, it shouldn't be too difficult to port them around, if we wanted to change the api. Probably would have to bump a version number though. >> 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. I've already offered :) It's pretty small change. The setup.py file becomes: ############################################################ from setuptools import setup, find_packages import markdown setup( name = 'markdown', version = markdown.__version__, url = "http://www.freewisdom.org/projects/python-markdown", author = "Manfred Stienstra and Yuri takhteyev", maintainer = "Yuri Takhteyev", maintainer_email = "yuri [at] freewisdom.org", description = "Python implementation of Markdown.", packages = find_packages(), py_modules = ["mdx_footnotes", "mdx_rss"], platforms = 'any', zip_safe = True, include_package_data = True, ) ############################################################ Then to use it, you have this in the plugin setup. The important thing is the entry_points: ############################################################ from setuptools import setup, find_packages import markdown setup( name='markdown-pygments', version='0.1', description="pygments extension for markdown.", platforms='any', zip_safe=True, packages=['markdown_pygments'], entry_points={ 'markdown': [ 'pygments = markdown_pygments:PygmentsExtension' ], }, ) ############################################################ And to load plugins, just do this: ############################################################ try: import pkg_resources except ImportError: pkg_resources = None ENTRY_POINT = 'markdown' def find_plugins(): if pkg_resources is None: return for entrypoint in pkg_resources.iter_entry_points(ENTRY_POINT): yield entrypoint.load() plugin_classes = find_plugins() for ext in extensions: config = extension_configs.get(ext, {}) for cls in plugin_classes: if cls.name == ext: e = cls(config) e.extendMarkdown(self, globals()) ############################################################ |