python-markdown-discuss

[Python-markdown-discuss] Passing Extension objects to markdown() and markdownFromFile() does not work

[Thomas t. C. <tte...@gm...>]

Since I can't seem to find an issue tracker, I'm posting this to the
mailing list. Please note that I'm not subscribed.

Using Markdown 2.0.3. At the bottom of
http://www.freewisdom.org/projects/python-markdown/Writing_Extensions
it says:

> However, Markdown will also accept an already existing instance of an extension. For example:
>
>     import markdown
>     import myextension
>     configs = {...}
>     myext = myextension.MyExtension(configs=configs)
>     md = markdown.Markdown(extensions=[myext])

This is partly true, and the code works. However, one would expect the
same thing to work when using the shortcut functions markdown() and
markdownFromFile(). But the former is defined as follows:

    def markdown(text,
                 extensions = [],
                 safe_mode = False,
                 output_format = DEFAULT_OUTPUT_FORMAT):
        md = Markdown(extensions=load_extensions(extensions),
                      safe_mode=safe_mode,
                      output_format=output_format)
        md.convertFile(input, output, encoding)

The load_extensions function expects a list of `basestring`s, and
chokes on Extension objects. The extra call seems redundant.

Is there a reason for this implementation, or is it better to remove
the call to load_extensions and pass the list of extensions directly,
like this?

        md = Markdown(extensions=extensions,
                      safe_mode=safe_mode,
                      output_format=output_format)

As an aside, the markdown() and markdownFromFile() functions don't
accept extension_configs either, which also seems unnecessarily
limiting.

Thomas

Re: [Python-markdown-discuss] Passing Extension objects to markdown() and markdownFromFile() does not work

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

Thomas, thanks for the feedback. It is much appreciated.

On Sun, Aug 29, 2010 at 7:14 AM, Thomas ten Cate <tte...@gm...> wrote:
> Since I can't seem to find an issue tracker, I'm posting this to the
> mailing list. Please note that I'm not subscribed.

Out issue tracker is here:

http://www.freewisdom.org/projects/python-markdown/Tickets

It should probably be linked from the front page. Yuri, seeing that
page is locked to avoid spam, could you add the link there.  People
seem to keep having the problem of not finding it.

> Using Markdown 2.0.3. At the bottom of
> http://www.freewisdom.org/projects/python-markdown/Writing_Extensions
> it says:
>
>> However, Markdown will also accept an already existing instance of an extension. For example:
>>
>>     import markdown
>>     import myextension
>>     configs = {...}
>>     myext = myextension.MyExtension(configs=configs)
>>     md = markdown.Markdown(extensions=[myext])
>
> This is partly true, and the code works. However, one would expect the
> same thing to work when using the shortcut functions markdown() and
> markdownFromFile(). But the former is defined as follows:
>
>    def markdown(text,
>                 extensions = [],
>                 safe_mode = False,
>                 output_format = DEFAULT_OUTPUT_FORMAT):
>        md = Markdown(extensions=load_extensions(extensions),
>                      safe_mode=safe_mode,
>                      output_format=output_format)
>        md.convertFile(input, output, encoding)
>
> The load_extensions function expects a list of `basestring`s, and
> chokes on Extension objects. The extra call seems redundant.

Funny you should mention this. Just the other day while working on
something else, I noticed that code int he wrapper function and
wondered about that very thing. I just didn't have the time to
investigate it. Thanks for confirming this for me.
>
> Is there a reason for this implementation, or is it better to remove
> the call to load_extensions and pass the list of extensions directly,
> like this?
>
>        md = Markdown(extensions=extensions,
>                      safe_mode=safe_mode,
>                      output_format=output_format)
>
> As an aside, the markdown() and markdownFromFile() functions don't
> accept extension_configs either, which also seems unnecessarily
> limiting.
>

For the record, this is for historical reasons. Extension configs can
be passed in as part of the extension name, In fact, the command line
script still does it this way. i.e.: ``extensions =
['extname(var=foo)']``. I suspect that is why the wrapper classes do
there own thing with the extensions. At one time, the class didn't
know about that syntax, only the wrapper functions did.

Anyway, I agree that the wrappers should accept anything that the
class will.  I've been intending to do some work on this. Thanks for
the reminder.

-- 
----
\X/ /-\ `/ |_ /-\ |\|
Waylan Limberg

Re: [Python-markdown-discuss] Passing Extension objects to markdown() and markdownFromFile() does not work

[Thomas t. C. <tte...@gm...>]

Thanks Waylan for the quick response.

On Mon, Aug 30, 2010 at 03:00, Waylan Limberg <wa...@gm...> wrote:
> Out issue tracker is here:
>
> http://www.freewisdom.org/projects/python-markdown/Tickets
>
> It should probably be linked from the front page. Yuri, seeing that
> page is locked to avoid spam, could you add the link there.  People
> seem to keep having the problem of not finding it.

Suggestions:
- Rename the "Advanced" tab to "Development". That's far more descriptive.
- Move the "Reporting Bugs" section from the "User Guide" tab to the
"Development" tab. Technically speaking, bug-reporting is a user
thing, but in this case the audience *will* consist mostly of
developers, and they'll probably expect it under "Development".

And while I'm at it:
- Move "Related Projects" from "Extensions" to "Overview". People will
want to know about this early on, before they choose to use this
software; for example, the markdown2 project might be a better choice
for some. (I would've used it if it weren't for the extensibility of
the original).

>> The load_extensions function expects a list of `basestring`s, and
>> chokes on Extension objects. The extra call seems redundant.
>
> Funny you should mention this. Just the other day while working on
> something else, I noticed that code int he wrapper function and
> wondered about that very thing. I just didn't have the time to
> investigate it. Thanks for confirming this for me.

Note that I didn't actually *try* changing it.

>> As an aside, the markdown() and markdownFromFile() functions don't
>> accept extension_configs either, which also seems unnecessarily
>> limiting.
>>
>
> For the record, this is for historical reasons. Extension configs can
> be passed in as part of the extension name, In fact, the command line
> script still does it this way. i.e.: ``extensions =
> ['extname(var=foo)']``. I suspect that is why the wrapper classes do
> there own thing with the extensions. At one time, the class didn't
> know about that syntax, only the wrapper functions did.

Ah, I see. Thanks for clearing that up.

> Anyway, I agree that the wrappers should accept anything that the
> class will.  I've been intending to do some work on this. Thanks for
> the reminder.

For completeness, now that you pointed me to the tracker, I've filed an issue:
http://www.freewisdom.org/projects/python-markdown/Tickets/000071

Don't worry too much about it. It's hardly a show-stopper, and if I
just create the Markdown object myself, the package does a great job.

Th.