Menu
▾
▴
python-markdown-discuss
|
From: David W. <wo...@cs...> - 2008-02-21 19:33:58
Attachments:
extensions.diff
|
At the moment, a list extension names is passed to Markdown(), and the Markdown class is responsible for loading them. This makes it harder to pragmatically load extensions. I have written a patch (attached) so that a list of extension modules will be passed to Markdown(). When running from the command line, extensions will be loaded as the command line arguments are parsed (through the new load_extension function). This will break the Markdown interface, though, so I haven't committed the code. What do you think? David |
|
From: David W. <wo...@cs...> - 2008-02-21 20:21:01
|
Like, for backwards compatibility? Yup, that's certainly a possibility. If there is general approval, I'll code it up. On 21-Feb-08, at 3:17 PM, Yuri Takhteyev wrote: > Can't we check for type of parameters to see whether they are names or > loaded modules? > > - yuri > > On Thu, Feb 21, 2008 at 11:33 AM, David Wolever > <wo...@cs...> wrote: >> At the moment, a list extension names is passed to Markdown(), and >> the Markdown class is responsible for loading them. >> This makes it harder to pragmatically load extensions. >> >> I have written a patch (attached) so that a list of extension >> modules >> will be passed to Markdown(). |
|
From: Waylan L. <wa...@gm...> - 2008-02-21 20:34:38
|
David, On Thu, Feb 21, 2008 at 2:33 PM, David Wolever <wo...@cs...> wrote: > At the moment, a list extension names is passed to Markdown(), and > the Markdown class is responsible for loading them. > This makes it harder to pragmatically load extensions. Harder in what way? I guess I'm not seeing the problem your trying to solve. Before we go and break the api and people have to rewrite all their extensions (we've had indications in the past that some people are using extensions they've never made public) I'd like to understand why, that's all. > > I have written a patch (attached) so that a list of extension modules > will be passed to Markdown(). One concern I have it that, unless I missed it, you have completely removed the `extension_configs` arg. You only allow key=value pairs separated by commas. The `extension_configs` arg makes it possible to easily set configs programicly or even pass in complex python data structures. Consider the Abbreviation Extension[1]. It accepts a dictionary of abbreviation definitions through the `extension_configs` arg among other ways to define abbreviations. One use case for that is that perhaps a project stores a list of abbreviations in a database or some other non flat-file format. That project's code could then gather those definitions into a dict and pass them in. Perhaps each user has a different list of definitions. Or sometimes the same abbreviation could have different meanings in different contexts, so the list is adjusted based upon the category of the document. You get the idea. I'd like to keep that ability. Although, that is my extension so I'm partial. [1]: http://achinghead.com/markdown/abbr/ > When running from the command line, extensions will be loaded as the > command line arguments are parsed (through the new load_extension > function). > > This will break the Markdown interface, though, so I haven't > committed the code. > > What do you think? > > David > > > > ------------------------------------------------------------------------- > This SF.net email is sponsored by: Microsoft > Defy all challenges. Microsoft(R) Visual Studio 2008. > http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/ > _______________________________________________ > Python-markdown-discuss mailing list > Pyt...@li... > https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss > > -- ---- Waylan Limberg wa...@gm... |
|
From: David W. <wo...@cs...> - 2008-02-21 20:59:12
|
On 21-Feb-08, at 3:34 PM, Waylan Limberg wrote:
> On Thu, Feb 21, 2008 at 2:33 PM, David Wolever
> <wo...@cs...> wrote:
>> At the moment, a list extension names is passed to Markdown(), and
>> the Markdown class is responsible for loading them.
>> This makes it harder to pragmatically load extensions.
> Harder in what way?
At the moment, you've got to put your extension in a module called
mdx_eggs.
In the case of DrProject (and, I believe, Trac... But there are
doubtless others), each component provides its own syntax (among
other things), so it is preferable to have a loop like:
for provider in wiki_syntax_providers:
extensions.append(provider.get_wiki_syntax())
where get_wiki_syntax() returns an object which is passed directly to
Markdown:
Markdown(extensions=extensions).convert("...")
>> I have written a patch (attached) so that a list of extension
>> modules
>> will be passed to Markdown().
> One concern I have it that, unless I missed it, you have completely
> removed the `extension_configs` arg. You only allow key=value pairs
> separated by commas. The `extension_configs` arg makes it possible to
> easily set configs programicly or even pass in complex python data
> structures.
The assumption, which I guess I didn't make clear, what that the
extensions passed to Markdown were "ready to go" -- they are just
waiting for a call to extendMarkdown().
So, if you were to be using the abbreviation extension, the code
would look something like this:
abbr = __import__("abbr")
abbr = abbr.makeExtension(("abbrs", (("RAM", "random access memory"),
("SSH", "secure shell"))))
Markdown(extensions = [abbr]).convert("I use SSH to check my free RAM")
Alternately, the load_extension function could be modified to take a
"config" parameter...
|
|
From: Waylan L. <wa...@gm...> - 2008-02-21 21:29:48
|
On Thu, Feb 21, 2008 at 3:58 PM, David Wolever <wo...@cs...> wrote:
> On 21-Feb-08, at 3:34 PM, Waylan Limberg wrote:
> > On Thu, Feb 21, 2008 at 2:33 PM, David Wolever
> > <wo...@cs...> wrote:
> >> At the moment, a list extension names is passed to Markdown(), and
> >> the Markdown class is responsible for loading them.
> >> This makes it harder to pragmatically load extensions.
> > Harder in what way?
> At the moment, you've got to put your extension in a module called
> mdx_eggs.
Ok, so your trying to remove the requirement that each extension has
to be in it's own file. I supose this would make a few things easier.
> >> I have written a patch (attached) so that a list of extension
> >> modules
> >> will be passed to Markdown().
> > One concern I have it that, unless I missed it, you have completely
> > removed the `extension_configs` arg. You only allow key=value pairs
> > separated by commas. The `extension_configs` arg makes it possible to
> > easily set configs programicly or even pass in complex python data
> > structures.
> The assumption, which I guess I didn't make clear, what that the
> extensions passed to Markdown were "ready to go" -- they are just
> waiting for a call to extendMarkdown().
>
> So, if you were to be using the abbreviation extension, the code
> would look something like this:
> abbr = __import__("abbr")
> abbr = abbr.makeExtension(("abbrs", (("RAM", "random access memory"),
> ("SSH", "secure shell"))))
> Markdown(extensions = [abbr]).convert("I use SSH to check my free RAM")
>
> Alternately, the load_extension function could be modified to take a
> "config" parameter...
I would prefer to see the config parameter. There are people who will
only ever use the extensions with no need to understand how they work.
Seeing we offered a arg before, lets keep it, or something similar, if
we can.
--
----
Waylan Limberg
wa...@gm...
|
|
From: David W. <wo...@cs...> - 2008-02-22 20:19:58
Attachments:
extensions2.diff
|
On 21-Feb-08, at 3:17 PM, Yuri Takhteyev wrote: > Can't we check for type of parameters to see whether they are names or > loaded modules? Yea, I think that makes the most sense. I was thinking about the common use-cases last night, and I realized that 98% of people probably just want to pass in the names -- so no need to make that more complex. In this patch, the extensions argument to Markdown can contain both strings (["abbr"]) or objects (or, I suppose, both). Strings are passed, along with their config from extension_configs, to load_extension, and then they are loaded as normal. I don't think I have made any changes to the API, and the few tests I've run on existing extensions seem to suggest that everything does the Right Thing. Comments? |
|
From: Yuri T. <qar...@gm...> - 2008-02-25 10:32:54
|
> I don't think I have made any changes to the API, and the few tests > I've run on existing extensions seem to suggest that everything does > the Right Thing. What happens when you run the test suite on it? If it works, check it in. - yuri |
|
From: Yuri T. <qar...@gm...> - 2008-02-25 10:34:43
|
P.S. Also, feel free to add as many comments to the code as you want. :) - yuri On Mon, Feb 25, 2008 at 2:32 AM, Yuri Takhteyev <qar...@gm...> wrote: > > I don't think I have made any changes to the API, and the few tests > > I've run on existing extensions seem to suggest that everything does > > the Right Thing. |
|
From: David W. <wo...@cs...> - 2008-02-25 21:55:29
|
On 25-Feb-08, at 5:32 AM, Yuri Takhteyev wrote: >> I don't think I have made any changes to the API, and the few tests >> I've run on existing extensions seem to suggest that everything does >> the Right Thing. > What happens when you run the test suite on it? If it works, check > it in. Yup, test suite runs without error. It's checked in at revision 78. |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X