python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] GSOC

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

I signed up as a mentor for Google's summer of code in case anyone is
interested in applying to work on Python-Markdown.  So, if you know a
student, let them know.

 - yuri

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

Re: [Python-markdown-discuss] git and gitorious

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

On Mon, Mar 24, 2008 at 9:48 PM, Yuri Takhteyev <qar...@gm...> wrote:
>
>
> > I see you have that working in sputnik. Would you be setting that up
> > for python-markdown as well? If so, that would only leave the list.
> > Would we use Google Groups or something, or leave it as is?
> >
> >
>
> I could.  As for the list, it's not like it needs to be all or nothing.  We
> could just keep the list on SF.

That wouldn't bother me to much. I rarely interact with the list other
than from my email client. But it would be nice to be completely rid
of SF.

> We could even keep the bug tracker there
> for now.

Actually, this is the part that I want to be rid of the most. I hate
using the SF bug tracker. Pretty much anything else would be better.
While better version control of the source is nice to have, IMO a
better bug tracker is necessary.



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

Re: [Python-markdown-discuss] git and gitorious

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

> I see you have that working in sputnik. Would you be setting that up
> for python-markdown as well? If so, that would only leave the list.
> Would we use Google Groups or something, or leave it as is?
>

I could.  As for the list, it's not like it needs to be all or nothing.  We
could just keep the list on SF.  We could even keep the bug tracker there
for now.

For others: the Sputnik bug tracker that Waylan is referring to is
http://sputnik.freewisdom.org/en/Tickets  It's a bit rought around the
edges, but has a plus of being integrated into the wiki and I want to try to
intergrate it with git, so that it would be possible to put Markdown into
the commit messages and into tickets: things like  "Fixes
[[Tickets/0000089]]" into commits and "I _tried_ to fix it with
[[Commits/503623b]] but this wasn't enough" into tickets.  Just waiting for
a few other pieces to be finished.  (Of course, this integration with git
will only work when looking at commits that are mounted onto the wiki - not
when looking at them on gitorious.)  Same with the list messages: see
[[List/git and gitorious]]  Anyway, that's a different project, so you don't
all need to convert to Sputnikism.  We don't even need to use Sputnik at
all.  I've been using it as a stop gap measure until infogami is released,
mostly because (1) it uses Markdown and (2) it was easy for me to install
it.

 - yuri




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

Re: [Python-markdown-discuss] git and gitorious

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

I've only heard good things about git and have been meaning to play
with it. At this point I'd be happy with pretty much anything but
sourceforge. I was going to object because we need a bug tracker, but
I see you have that working in sputnik. Would you be setting that up
for python-markdown as well? If so, that would only leave the list.
Would we use Google Groups or something, or leave it as is?

On Mon, Mar 24, 2008 at 8:36 PM, Yuri Takhteyev <qar...@gm...> wrote:
> Waylan's patch reminded me of something I wanted to bring up: should we
> consider moving from SF's subversion to something a tiny little bit less
> sucky?  I recently moved Sputnik over to a git repository hosted by
> gitorious.org and I since can't stop telling people how much in love I am
> with both git and gitorious.  I wake up in the morning and look forward to
> the day knowing that if someone emails me a patch it will be in form of a
> link to something like:
>
> http://gitorious.org/projects/sputnik/repos/mainline/commits/3028915518ebdc0574bf3255f2ffa48c82e395eb
>
> And that it would then take me no time to integrate it, even if my own code
> has moved on.
>
> There is also a nice open-sourcy thing about gitorious (and git more
> generally), in that people don't need my permission to start making clones
> and commits (into their clones).  They just need to email me a list of
> commits later.  Click around the Sputnik gitorious repository and compare
> this with what we have now:
>
> Gitorious: http://gitorious.org/projects/sputnik/
> SF:  http://python-markdown.svn.sourceforge.net/viewvc/python-markdown/
>
>  - yuri
>
> --
> http://sputnik.freewisdom.org/
> -------------------------------------------------------------------------
>  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...

[Python-markdown-discuss] git and gitorious

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

Waylan's patch reminded me of something I wanted to bring up: should we
consider moving from SF's subversion to something a tiny little bit less
sucky?  I recently moved Sputnik over to a git repository hosted by
gitorious.org and I since can't stop telling people how much in love I am
with both git and gitorious.  I wake up in the morning and look forward to
the day knowing that if someone emails me a patch it will be in form of a
link to something like:

http://gitorious.org/projects/sputnik/repos/mainline/commits/3028915518ebdc0574bf3255f2ffa48c82e395eb

And that it would then take me no time to integrate it, even if my own code
has moved on.

There is also a nice open-sourcy thing about gitorious (and git more
generally), in that people don't need my permission to start making clones
and commits (into their clones).  They just need to email me a list of
commits later.  Click around the Sputnik gitorious repository and compare
this with what we have now:

Gitorious: http://gitorious.org/projects/sputnik/
SF:  http://python-markdown.svn.sourceforge.net/viewvc/python-markdown/

 - yuri

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

Re: [Python-markdown-discuss] Exploring testing

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

I think it will be useful if we use it to write something that we don't have
at the moment, such as a unit testing framework.  Such a framework would
serve a different purpose from my current test framework, which does
black-box tests.
If you write a unit testing framework, it would do us much good.  But it
will take some work, even with nose, much of which would go into deciding
what to test and what not to test.

On the other hand, I don't see any point in just porting the existing
black-box testing framework to nose.  We lose a lot and we gain nothing.

- yuri

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

Re: [Python-markdown-discuss] Exploring testing

[David W. <wo...@cs...>]

On 24-Mar-08, at 1:33 PM, Waylan Limberg wrote:
> ...
> Unrelated to my work on python-markdown I was checking out
> [python-nose][] to see what the recent hype was all about. Turns out
> its basically a clone of [py.test][] that claims to be "less magic".
> Now I had personally never used py.test, so that didn't mean much to
> me, although "less magic" sounded good. Anyway, in browsing through
> the nose documentation I stumbled upon [Test generators][] (scroll to
> bottom of that page) which I don't remember seeing before. It turns
> out [py.test has them too][]. Simply put, you can write one test which
> runs through a loop and generates (using `yeild`) a separate
> (sandboxed) unit test for each cycle of the loop.
> ...
Looks neat!
I've been using nose for a while now, and it's been really nice.  I  
would certainly be in support of a nose-base test suite...

[Python-markdown-discuss] Exploring testing

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

I recently came up with a little different approach to testing
python-markdown and would like some feedback. Sorry if this is a
little long.

Unrelated to my work on python-markdown I was checking out
[python-nose][] to see what the recent hype was all about. Turns out
its basically a clone of [py.test][] that claims to be "less magic".
Now I had personally never used py.test, so that didn't mean much to
me, although "less magic" sounded good. Anyway, in browsing through
the nose documentation I stumbled upon [Test generators][] (scroll to
bottom of that page) which I don't remember seeing before. It turns
out [py.test has them too][]. Simply put, you can write one test which
runs through a loop and generates (using `yeild`) a separate
(sandboxed) unit test for each cycle of the loop.

[python-nose]: http://code.google.com/p/python-nose/
[py.test]: http://codespeak.net/py/dist/test.html
[Test generators]: http://code.google.com/p/python-nose/wiki/WritingTests
[py.test has them too]:
http://codespeak.net/py/dist/test.html#generative-tests-yielding-more-tests

Immediately, I saw this as an interesting way to test markdown output.
The test class should be able to loop through a list of files in a
given directory and each file's output could be it's own separate
unittest. I threw some code together (see attachment) and it Just
Works(TM). Cool!

This is by no means production ready. For starters, I'm only doing a
`output_string == expected_output_string` type check and some of the
existing tests (4 to be precise) fail because of some minor whitespace
issues (I think the dom behavior was changed after those tests were
created). There is no diff of the failing code produced or even a nice
html report like we get in the current framework. I'm not going to
spend the time to work those things out until I know this will be
used. Although I did find [xmldiff][], which may be an interesting
approach regardless of the testing framework used.

[xmldiff]: http://www.logilab.org/859

There are some interesting possibilities this opens up though. I seem
to recall someone recently complaining on this list about there not
being any api tests. This would make it easy to integrate them in with
the syntax tests. Additionally, the way I'm initiating the markdown
class, it's easy to override in a subclass with your own custom args
for that batch of tests. It certainly is more flexible in that
respect. In fact, I *will most likely* be adopting something much like
this for some of my extensions (particularly mete-data and the other
extensions it supports) regardless of what happens with
python-markdown's testing.

I should mention that the current testing framework runs each test
multiple times for performance and memory usage measurements. I
imagine we would lose that if we went with something like this.
There's also the fact that neither nose nor py.test are part of the
standard python library. However, I would imagine the average user
will never use the tests anyway, so do we even care?

So what do you think? It this something worth pursuing or not?

P.S.: If your testing this out, just copy the attached file into the
"tests" directory. Assuming python-nose is installed on your system,
on the command line from within the "tests" directory, run `nosetests`
with no args and nose will find the tests and run them.

I should also mention that I wasn't too concerned with the color I
painted this shed. I just wanted to get something that worked. So If
you have any better names for things, please share.
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Markdown package with debug statements

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

On Wed, Mar 5, 2008 at 5:49 PM, Malthe Borch <mb...@gm...> wrote:
>
>  I can see that there is no test suite included with the markdown
>  package; if believe that it would beneficial to move these debugging
>  statements out of the package and into a test suite (where you get to
>  explicitly define what you expect to see in those statements).

First, IIRC the debug statements are only in the wrapper functions. I
would think that this is the most likely that people using markdown
would want to debug. In debugging their app which uses markdown, they
might be unsure that their app is actually passing things on to
markdown correctly. Those debug messages allow them to easily check
that. I think that adds enough value to leave them.
>
>  This way, you can let people know why you're interested in the output
>  and what you expect to see.
>
>  By the way: I'm only starting this thread because the markdown package
>  is great work and I'm a happy user :-)

Glad to hear it, and glad you brought it up. The testing framework is
actually what I want to focus on now that 1.7 it out of the door. I
had started to develop some regression tests for the api, but
unfortunately lost them in a hard drive failure (and no I didn't have
a proper backup). I guess it's back to the drawing board on that. Any
input others may have is more than welcome.
>
>  \malthe
>

To be

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

Re: [Python-markdown-discuss] Markdown package with debug statements

[Malthe B. <mb...@gm...>]

On 05/03/2008, Yuri Takhteyev <qar...@gm...> wrote:
>  Some debug messages are very specific to a particular bug.  Once the
>  bug is fixed, they can be removed.  Except that of course you are
>  never 100% sure that the change you made fully fixes the bug.  Sure it
>  passes specific tests, but someone will come up with another test that
>  will fail.  (Or you will come up with one in the shower the next
>  morning.)  So, if the bug fix is tentative, it makes sense to leave
>  the debug statements in, I think.  It does make sense to clean those
>  up eventually.  Additionally, some debug messages come in handy for
>  pretty much any debugging session.  In those cases it makes sense to
>  leave them around for longer.

I can see that there is no test suite included with the markdown
package; if believe that it would beneficial to move these debugging
statements out of the package and into a test suite (where you get to
explicitly define what you expect to see in those statements).

This way, you can let people know why you're interested in the output
and what you expect to see.

By the way: I'm only starting this thread because the markdown package
is great work and I'm a happy user :-)

\malthe

Re: [Python-markdown-discuss] Markdown package with debug statements

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

Malthe,

First, there are only two debug messages at the moment in subversion.
But I also disagree with the principle.  Code is never bug free.
People always end up finding new bugs.  Or ask for features.  Or
suggest optimizations.  In fact, the more mature the project is, the
more people use it, and the more bugs they report and the more
suggestions they make.  Which means that every now and then we have to
go an debug the code.  To paraphrase a well-known quotation, "a
software project is never finished, only abandoned."  Python-markdown
has not been abandoned yet, therefore it is not finished.

Some debug messages are very specific to a particular bug.  Once the
bug is fixed, they can be removed.  Except that of course you are
never 100% sure that the change you made fully fixes the bug.  Sure it
passes specific tests, but someone will come up with another test that
will fail.  (Or you will come up with one in the shower the next
morning.)  So, if the bug fix is tentative, it makes sense to leave
the debug statements in, I think.  It does make sense to clean those
up eventually.  Additionally, some debug messages come in handy for
pretty much any debugging session.  In those cases it makes sense to
leave them around for longer.

Tests are not a replacement for debug messages.  A test suit helps you
identify regressions, but it can't help you find what _causes_ them.

>  I think a good use for log statements is when rare or unexpected
>  events happen, or if the user of the package needs some information.

That's why the debug messages are filtered out by default.  You need
to ask for them to see them.  Default logging level is CRITICAL.

 - yuri

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

Re: [Python-markdown-discuss] Markdown package with debug statements

[Malthe B. <mb...@gm...>]

Hey Waylan, ––

Thanks for your reply.

On 05/03/2008, Waylan Limberg <wa...@gm...> wrote:
>  If your wondering why this is necessary for a command line script like
>  markdown, remember that many (perhaps most) are using markdown.py
>  behind a web server which would require the ability to reconfigure
>  logging. Such a user could conceivably redirect such messages to their
>  servers error log  for review when problems are encountered. In fact,
>  in most web server configurations this is the only way to debug a
>  problem.

That's a good point, although I would think that at some point, the
package reaches a state of maturity where automated tests should take
the place of any runtime debugging. That is, ––– if the output is not
what's expected, it should be proven in a test such that it can be
fixed.

I think a good use for log statements is when rare or unexpected
events happen, or if the user of the package needs some information.

Instead of having the debug statement in the markdown package, I think
it should be in the application using markdown, if that application is
still in development.

\malthe

Re: [Python-markdown-discuss] Markdown package with debug statements

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

On Wed, Mar 5, 2008 at 12:08 PM, Malthe Borch <mb...@gm...> wrote:
> Hey Waylan, ––
>
>  In the 1.7-release of markdown there are some DEBUG statements left in
>  the code; is that on purpose?
>

Malthe,

I'm assuming you are referring to `message` statements set to level
DEBUG, like so:

    message(DEBUG, "a debug message")

If so, yes, that was intentional. If you notice, starting about line
36 we are using python's logging module and by default the logger is
set to level CRITICAL. That being the case any lower level (like
DEBUG) is ignored. However, if one wanted to do some debugging, a
simple change of the logger level would make that easy. This is
actually the intended purpose of the logging module. Much better than
adding (and latter remembering to find and remove) print statements.

If you'd like more information on the logging module, see the
[docs][1] or [PEP 282][2].

[1]: http://docs.python.org/lib/module-logging.html
[2]: http://www.python.org/dev/peps/pep-0282/

As the PEP says (under the "Configuration" section):

> The main benefit of a logging system like this is that one can
> control how much and what logging output one gets from an
> application without changing that application's source code.
> Therefore, although configuration can be performed through the
> logging API, it must also be possible to change the logging
> configuration without changing an application at all.

If your wondering why this is necessary for a command line script like
markdown, remember that many (perhaps most) are using markdown.py
behind a web server which would require the ability to reconfigure
logging. Such a user could conceivably redirect such messages to their
servers error log  for review when problems are encountered. In fact,
in most web server configurations this is the only way to debug a
problem.

I hope that answers your question. However, if you actually found some
print statements or such that I missed, please let me know where and
I'll remove them.

Either way, thanks for your feedback. It's always appreciated. In
fact, this reminds me that I should probably document how to configure
the logger for a few basic use cases.

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

Re: [Python-markdown-discuss] Default Pattern regular expression

[David W. <wo...@cs...>]

Alright, I've replaced the Pattern regex with "(.*?)", and that found  
a few bugs in other patterns (which were doing the wrong thing with  
greedy/non-greedy regexes).  I've fixed that and added a simple test  
case in rev 83.

On 29-Feb-08, at 4:30 PM, Waylan Limberg wrote:

> I was going to make that change myself and have tested it. However, I
> never did commit it because it would seem to me that wrapping the
> patterns in (.*) is unnecessary. However, the reliance on those goes
> deeper that I initially thought. So, sure, if your satisfied that the
> tests pass, go ahead and make that change.
>
> We may come upon a few edge cases later and have to tweak a few of the
> patterns, but so be it. Personally, I think a few of them could be
> reworked anyway. I just haven't taken the time to do it.
>
> On Fri, Feb 29, 2008 at 3:51 PM, David Wolever  
> <wo...@cs...> wrote:
>> At the moment, the Pattern class defaults to using the regular
>>  expression ``^(.*)<user patter>(.*)$`` to match everything.  This
>>  becomes problematic, however, if the user's pattern has an optional
>>  prefix (ie: ``(\!?stuff)`` -- the ! (if it exists) will be  
>> matched as
>>  part of the (.*) instead of the (\!?stuff)).
>>
>>  I've replaced the regular expression with ``^(.*?)%s(.*?)$`` -- the
>>  non-greedy sides should do the trick (at least in my situation).
>>
>>  Now, is there any reason this shouldn't be used generally?  I can't
>>  think of any expression which it would break... But,  admittedly, my
>>  regex-foo is low.
>>
>>  Thanks,
>>  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...

[Python-markdown-discuss] Default Pattern regular expression

[David W. <wo...@cs...>]

At the moment, the Pattern class defaults to using the regular  
expression ``^(.*)<user patter>(.*)$`` to match everything.  This  
becomes problematic, however, if the user's pattern has an optional  
prefix (ie: ``(\!?stuff)`` -- the ! (if it exists) will be matched as  
part of the (.*) instead of the (\!?stuff)).

I've replaced the regular expression with ``^(.*?)%s(.*?)$`` -- the  
non-greedy sides should do the trick (at least in my situation).

Now, is there any reason this shouldn't be used generally?  I can't  
think of any expression which it would break... But,  admittedly, my  
regex-foo is low.

Thanks,
David

Re: [Python-markdown-discuss] mdx_footnotes

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

>  This is a page with [^This is a footnote!]some footnotes.
>  And I'm running with:
>  ./markdown.py -x footnotes test
>  But that just produces:
>  <p>This is a page with <sup id="fnr1-119077789"><a
>  href="#fn1-119077789">1</a></sup>some footnotes.
>  </p>
>
>  (it's missing the footnote definitions)

You need to provide the foonote definitions in your source!

    Footnotes[^1] have a label[^label] and a definition.

    [^1]: This is a footnote
    [^label]: A footnote on "label"

If you skip the definitions in your source, you won't get them in your
output either. :)

>  Is anyone using it successfully?

I am not using it actively, but I just tested it out of SVN and it worked.

 - yuri

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

[Python-markdown-discuss] mdx_footnotes

[David W. <wo...@cs...>]

I've been fiddling around with mdx_footnotes, and I've been having  
some trouble getting it to work.
The input is:
This is a page with [^This is a footnote!]some footnotes.
And I'm running with:
./markdown.py -x footnotes test
But that just produces:
<p>This is a page with <sup id="fnr1-119077789"><a  
href="#fn1-119077789">1</a></sup>some footnotes.
</p>

(it's missing the footnote definitions)

I've peeked at the code, and it seems like this is because nothing is  
calling setFootnote... But I could be wrong.

Is anyone using it successfully?

Re: [Python-markdown-discuss] MarkdownException?

[David W. <wo...@cs...>]

Ok, I've attached a patch which adds a MarkdownException class and  
then raises it at a few opportune moments.

I've also added a bit of checking on the -s argument.

What do you think?

On 26-Feb-08, at 12:04 PM, David Wolever wrote:

> On 26-Feb-08, at 3:39 AM, Yuri Takhteyev wrote:
>> I think the thing to do here is to raise an exception, the only
>> question is what to call it.  MarkdownException would be reasonable,
>> though perhaps something more specific would make more sense?
> I'd say MarkdownException is pretty clear :)
>
> Then, to make the command-line people happy, the "if __name__ ==
> "__main__":..." code could be wrapped in a "try: ... except
> MarkdownException:  ... except Exception: ..." so users don't get
> tracebacks on MarkdownExceptions.

Re: [Python-markdown-discuss] MarkdownException?

[David W. <wo...@cs...>]

On 26-Feb-08, at 3:39 AM, Yuri Takhteyev wrote:
> I think the thing to do here is to raise an exception, the only
> question is what to call it.  MarkdownException would be reasonable,
> though perhaps something more specific would make more sense?
I'd say MarkdownException is pretty clear :)

Then, to make the command-line people happy, the "if __name__ ==  
"__main__":..." code could be wrapped in a "try: ... except  
MarkdownException:  ... except Exception: ..." so users don't get  
tracebacks on MarkdownExceptions.

Re: [Python-markdown-discuss] MarkdownException?

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

> Is there any reason nothing explicitly raises exceptions?  I've uses
>  sys.exit() in load_extension, which in retrospect is probably the
>  wrong thing to do (if Markdown is being used as a module)... But it
>  also didn't feel right to either return None or create an exception
>  class and raise that.

Yes, there is a reason: procrastination.

Yes, sys.exit(1) is not appropriate here nor is returning None. (And I
should have caught this!)

I think the thing to do here is to raise an exception, the only
question is what to call it.  MarkdownException would be reasonable,
though perhaps something more specific would make more sense?

Greg's code review
(http://www.third-bit.com/pages/reviewing-markdown.html) noted a few
other cases where we should do what he calls "if/then/else/oops"
instead of "if/then/else".  If we fix those, then this would give us
more opportunities to use MarkdownException.

 - yuri

[Python-markdown-discuss] MarkdownException?

[David W. <wo...@cs...>]

Is there any reason nothing explicitly raises exceptions?  I've uses  
sys.exit() in load_extension, which in retrospect is probably the  
wrong thing to do (if Markdown is being used as a module)... But it  
also didn't feel right to either return None or create an exception  
class and raise that.

Re: [Python-markdown-discuss] Changing the way extensions are loaded

[David W. <wo...@cs...>]

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.

Re: [Python-markdown-discuss] Changing the way extensions are loaded

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

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.

Re: [Python-markdown-discuss] Changing the way extensions are loaded

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

>  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

Re: [Python-markdown-discuss] Changing the way extensions are loaded

[David W. <wo...@cs...>]

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?