python-markdown-discuss

[Python-markdown-discuss] future changes for markdown

[Erick T. <ida...@us...>]

 > 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

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/

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

[Erick T. <ida...@us...>]

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

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

[Sam's L. <sam...@gm...>]

>
>
> > 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?



Personally, I think it would be fine to only support Python 2.4 and above.
:)