|
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())
############################################################
|