python-markdown-discuss

[Python-markdown-discuss] second Markdown() instance clobbers the first?

[Eric A. <er...@ab...>]

I'm using Markdown with Django, not as a template filter but by  
running database text through markdown as it is saved, so that the  
markdown text is saved into one field, and HTML converted text is  
saved into another field. I want different behavior for different  
models, so I instantiate two Markdown objects, one for filtering blog  
entry text (safe_mode is off) and one for filtering comment text  
(safe_mode is set to 'remove').

Both are instantiated at the top of a single models.py module, like  
this:

safe_md = Markdown()
remove_md = Markdown(safe_mode='remove')

What I've found is that the second instance seems to override the  
first. Blog text run through safe_md.convert() has its HTML removed,  
as though its safe_mode were set to 'remove'. I "fixed" the problem by  
commenting out the second instance, and later I moved it inside a  
function where it's hidden.

This isn't at all how I expected this to work, and I wonder if it's a  
bug with Markdown or with my expectations. I thought it might have had  
to do with Django, perhaps threading or something, but it behaves the  
same way in the Python interpreter. Can someone explain what's going  
on here?

TIA,

Eric

Re: [Python-markdown-discuss] second Markdown() instance clobbers the first?

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

Your expectations are correct, the behavior is wrong, so it's a bug.

The reason for this is that it looks like different instances of
Markdown share the same instances of patterns.  For instance, we have:

REFERENCE_PREPROCESSOR = ReferencePreprocessor()

So, REFERENCE_PREPROCESSOR is a module-level variable and the instance
is shared.  This gives later instances an opportunity to change it
during initialization.

I think we have two options: we can either make all the patterns
stateless, and give them an instance of Markdown() if they want to
look up config parameters.  Or we could give each instance of Markdown
it's own set of patterns.  I am leaning on the second solution, but
note the downside: the we are relying on those variables in the
extensions, so this would break many of the extensions.  If we'll be
doing this, we might as well make the effort now to add a treap for
ordering the preprocessor, as Ben Wilson suggested last year.

Then, we would have something like:

    self.preprocessors = Treap('header', HeaderPreprocessor())
    self.preprocessors.insert_after('header', 'line', LinePreprocessor())
    self.preprocessors.insert_after('line', 'reference',
ReferencePreprocessor())

In the footnote extension we can then have:

    md.preprocessors.insert_before('reference', 'footnote',
FootnotePreprocessor())

What do you guys think?

- yuri

On Thu, Sep 25, 2008 at 11:39 PM, Eric Abrahamsen <er...@ab...> wrote:
> I'm using Markdown with Django, not as a template filter but by
> running database text through markdown as it is saved, so that the
> markdown text is saved into one field, and HTML converted text is
> saved into another field. I want different behavior for different
> models, so I instantiate two Markdown objects, one for filtering blog
> entry text (safe_mode is off) and one for filtering comment text
> (safe_mode is set to 'remove').
>
> Both are instantiated at the top of a single models.py module, like
> this:
>
> safe_md = Markdown()
> remove_md = Markdown(safe_mode='remove')
>
> What I've found is that the second instance seems to override the
> first. Blog text run through safe_md.convert() has its HTML removed,
> as though its safe_mode were set to 'remove'. I "fixed" the problem by
> commenting out the second instance, and later I moved it inside a
> function where it's hidden.
>
> This isn't at all how I expected this to work, and I wonder if it's a
> bug with Markdown or with my expectations. I thought it might have had
> to do with Django, perhaps threading or something, but it behaves the
> same way in the Python interpreter. Can someone explain what's going
> on here?
>
> TIA,
>
> Eric
>
> -------------------------------------------------------------------------
> This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
> Build the coolest Linux based applications with Moblin SDK & win great prizes
> Grand prize is a trip for two to an Open Source event anywhere in the world
> http://moblin-contest.org/redirect.php?banner_id=100&url=/
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



-- 
http://sputnik.freewisdom.org/

Re: [Python-markdown-discuss] second Markdown() instance clobbers the first?

[Waylan L. <wa...@gm...>]

On Sat, Oct 4, 2008 at 3:12 PM, Yuri Takhteyev <qar...@gm...> wrote:
>
> I think we have two options: we can either make all the patterns
> stateless, and give them an instance of Markdown() if they want to
> look up config parameters.  Or we could give each instance of Markdown
> it's own set of patterns.  I am leaning on the second solution, but
> note the downside: the we are relying on those variables in the
> extensions, so this would break many of the extensions.  If we'll be
> doing this, we might as well make the effort now to add a treap for
> ordering the preprocessor, as Ben Wilson suggested last year.
>
[snip]
>
> What do you guys think?
>

I agree. I'm leaning toward the second option as well. Btw, Ben must
have failed to copy the list on the last few emails he sent you
because last I knew we was still working on it. Yet, a few times since
then, you've made some comments that seem to indicate you saw some
code of his.

In any event, if we are going to do anything link this, it should
definitely be before we release 2.0. The move to ET already broke
existing extensions and seeing we havn't released since then, we might
as well keep going with the changes. I suspect most people are still
using 1.7 with any private extensions they've written so they'll have
to update witht he next release anyway.

-- 
----
Waylan Limberg
wa...@gm...