python-markdown-discuss — A general purpose discussion list

[Python-markdown-discuss] Ticket 74

[Gerry L. <gjl...@gm...>]

Started looking into this one and I think I uncovered a somewhat related
bug.  If a child element's tail is assigned, then neither the text nor
tail show up in the output.

For example:

    import markdown
    from markdown.inlinepatterns import Pattern

    class MyPattern(Pattern):

        def handleMatch(self, m):

            el = markdown.etree.Element('p')
            el.text = markdown.AtomicString('an *atomic*')
            c1 = markdown.etree.SubElement(el, 'span')
            c1.text = markdown.AtomicString('*string*')
            c1.tail = markdown.AtomicString('`not code`')
            return el

    class MyExtension(markdown.Extension):

        def extendMarkdown(self, md, md_globals):
            patt = MyPattern(r'::(.*?)::')
            md.inlinePatterns.insert(0, 'foobar', patt)



    ext = MyExtension(None)
    md = markdown.Markdown(extensions=[ext], output_format="xhtml1")
    html = md.convert('here is ::mypattern::')

    print html

The resulting output is:
    <p>here is <p>an *atomic* </p>
    </p>

As opposed to:
    <p>here is <p>an *atomic*<span>*string*</span>`not code`</p>
    </p>

This is probably out in the weeds as far as usage goes.  Also, I'm
surprised that this doesn't cause normal usage issues- surely the tree
parser receives similar input in normal use situations(ie when parsing a
file of Markdown text).  An element with a child with text and tail
can't be that unusual.

Anyway, I'll be investigating it a bit more.

Regards-
Gerry LaMontagne

[Python-markdown-discuss] How to make fenced_code play nice with code_hilite?

[Italo M. <ita...@gm...>]

Well, just had a fight with default code syntax in markdown plus
python-markdown, so, by suggestion of Waylan, i tried fenced_code extension.
Well, this extension looks nice but doesn't play nice with code_hilite.
code_hilite simply won't color a thing if fenced_code is there. Is there a
workaround for that?

-- 
"A arrogância é a arma dos fracos."

===========================
Italo Moreira Campelo Maia
Graduado em Ciência da Computação - UECE
Desenvolvedor WEB e Desktop (Java, Python, Lua)
Coordenador do Pug-CE
-----------------------------------------------------
http://www.italomaia.com/
http://twitter.com/italomaia/
http://eusouolobomau.blogspot.com/
-----------------------------------------------------
turtle linux 910 - http://tiny.cc/blogturtle910
===========================

Re: [Python-markdown-discuss] Ticket 62

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

On Sun, Aug 29, 2010 at 10:33 PM, Gerry LaMontagne <gjl...@gm...> wrote:
> I've looked into this bug and have worked up a potential fix that passes
> the regression test suite.  However, I think it requires some more strenuous
> testing.
>
> First, an explanation(see [here][0] for the bug description):
>
[snip]
> [0]: http://www.freewisdom.org/projects/python-markdown/Tickets/000062
>
> Regards-
> Gerry LaMontagne
>

Gerry, Sorry I haven't responded yet, but I've been swamped and wanted
to give some serious thought to this before responding. I see you made
a merge request last night.

I'm leaving for vacation tomorrow morning (finally) and I'm not sure
when I'll get a chance to look at it. Just wanted to let you know I'm
not ignoring you. Fixing the issues with the html parser is at the top
of my list. Thanks for taking the time to work on this, because I sure
haven't had the time.

-- 
----
\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.

[Python-markdown-discuss] Ticket 62

[Gerry L. <gjl...@gm...>]

I've looked into this bug and have worked up a potential fix that passes
the regression test suite.  However, I think it requires some more strenuous 
testing.

First, an explanation(see [here][0] for the bug description):

The problem boils down to the end-tag search in the
HtmlBlockPreprocessor class.  Specifically, in the `_get_right_tag`
method, a `block.rfind` is used to find the last match in the string for an
end-tag.  This works well for nested tags such as:

<div>
        <div>
                <div>
                        foo
                </div>
        </div>
</div>

This case is covered pretty exhaustively in the test suite.

The edge case that trips things up is when, within a single block of
processing text, there are consecutive HTML tags.  In particular, when
the second tag is buried within another block tag.  So, considering the
example text from the bug report:

<p>foo</p>
<ul>
<li>
<p>bar</p>
</li>
</ul>

The search returns the end p-tag that's in the middle of the list.  So
the next set of processing starts with the end tags for the list.  

Adding a blank line between the paragraph and the list fixes the problem
because it forces the paragraph to be processed separately from the
list.  Thus, the end-tag for the list paragraph does not get confused
with the end-tag for the first paragraph.

The fix I've got replaces the `block.rfind` with a custom search
function.  This approach seemed to be the one that was the least
invasive and it currently passes the regression test suite.  However, I
wanted to exercise it more thoroughly and was thinking some
"in-the-wild" examples would be a good way to gain more confidence that
this fix won't break current installs.  So, any offers will be
appreciated.

I'll build up some other tests on my own in the mean time.  Other
suggestion welcome as well.

[0]: http://www.freewisdom.org/projects/python-markdown/Tickets/000062

Regards-
Gerry LaMontagne

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

[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] Two New Extensions: Superscript and Subscript

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

> 1. Superscript:  http://github.com/sgraber/markdown.superscript
>
> 2. Subscript: http://github.com/sgraber/markdown.subscript

Thanks. And thanks for updating the wiki.

- yuri

Re: [Python-markdown-discuss] Adding an extension to convert LaTeX(ish) to MathML

[Andrew S. <and...@ma...>]

Hi!

Thanks for the quick initial response.

On Mon, Aug 02, 2010 at 12:45:55PM -0400, Waylan Limberg wrote:
> Hmm, I'm not a real big fan of Swig myself (mostly through my own lack of
> success in compiling a few packages). It's not that Swig is bad (it
> certainly has it's merits), but this just feels like too heavy of
> a dependency for it to be shipped with Python-Markdown.

Understood.

> Of course, extensions can certainly live as third party packages, so
> it may be appropriate that way.

For me, this would be absolutely fine.  I wasn't angling for more.

> > required (thus meaning that it can _internally_ cope with different
> > browser requirements).
> 
> While this may be appropriate on a case by case basis for certain
> projects, this seems like a bad idea to me for a general use
> extension. Browser sniffing and making images available for a web
> server to serve separate from the markdown document just doesn't
> belong here.  Of course, if an individual project needs those
> features, they could certainly hack up the basic extension to fit
> their specific needs.

Absolutely!  I misspoke a little.  I would propose that the extension have
a switch by which it can be told to produce MathML, SVG, or PNG.  Then the
calling script can do the browser selection or just choose one and so pass the
appropriate option to the extension.  Alternatively, the extension can just do
the conversion to MathML and then the calling script can further pass the
whole XHTML document through SVGMath to do the rest.

I mentioned this because one of the major issues with MathML is its lack of
browser support.  But it's chicken-and-egg: people don't want to adopt MathML
until it's supported widely, but the push to get it supported widely won't
come until lots of people use it and see how good it is.  So being able to
offer a choice is a way of getting people to use MathML without losing their
audience.

> On the other hand, I haven't looked at the solutions offered in other
> languages. Maybe those issues have already been worked out and a
> default behavior has been established, in which case we could simply
> copy it.

As I said, I've done the PHP coding and the guy who currently maintains
itex2MML has done the ruby version.  A perl version is no doubt not far off
(that one I could do myself but don't have an application to hand right now in
which to use it!).

> Any chance we could see the source of your CGI script?

Yes of course!  I should have put that in my earlier email.  My apologies.  My
additions to itex2MML are available at:

http://www.math.ntnu.no/~stacey/code/itexToMML

The python cgi script is in cgi-bin/itex.py (relative to that link).  The
whole thing is a bzr repository.  Note that this isn't a live version but just
the code.

> Again, thanks for taking the time to get this started.

No problem!  Thanks for the quick initial reply,

Andrew

[Python-markdown-discuss] Adding an extension to convert LaTeX(ish) to MathML

[Andrew S. <and...@ma...>]

Dear Python Markdowners,

Is anyone interested in helping to write an extension that would convert
LaTeX(ish) syntax to MathML?

There is a c++ library called itex2MML which converts a subset of LaTeX
mathematics syntax to MathML.  Using swig, it can be compiled with the
appropriate "hooks" to allow it to be called from a python script.  Using
a bit of "cargo cult" programming (a term I've just heard about and which
describes my approach to programming perfectly), I've written a CGI script
that uses this to convert this LaTeXish language (known as iTeX) to MathML.
Combining it with the existent python program SVGMath, and the libcairo
extensions, it is possible to convert it further to SVG and thence to PNG, if
required (thus meaning that it can _internally_ cope with different browser
requirements).

It strikes me that this would be an extremely useful thing to add to the
python markdown suite.  This already exists in one of the Ruby variants of
Markdown (Maruku) and is used in the Instiki wiki engine.  I've written the
PHP code necessary to do this and am using it in a PHP forum.  Having a python
implementation would enable things like the OSQA platform to be used for
proper mathematics.  Indeed, because python already has the SVGMath program,
there are considerable advantages in having this for python than any of the
other languages.

The only drawback is that I've no experience of programming in python, beyond
that little hackery needed for the CGI script.  So I wondered if there was
anyone here who would be interested in doing the python bit of it.

To be clear: I already have the extensions, and from doing the PHP version
I already know some of the potential pitfalls that may be encountered.  So it
really is just the ability to program in python that I'm lacking!  And much as
I would benefit from learning another language, it would be far quicker and
produce a far more robust extension if someone who knew about python already
was prepared to help!

To see the CGI script in action, go to:

http://www.mathforge.org/itex/itex.html

Thanks,

Andrew Stacey

[Python-markdown-discuss] Two New Extensions: Superscript and Subscript

[Shane G. <sg...@gm...>]

Just joined the list to let people know that I released two extensions for
Markdown:

1. Superscript:  http://github.com/sgraber/markdown.superscript

2. Subscript: http://github.com/sgraber/markdown.subscript

They're pretty basic extensions...they just allow an author to add
superscript and subscript markup to a Markdown document.  Superscripts use a
carrot, '^', to denote the beginning/end of a superscripted section of text
and a tilde, '~', denotes subscripting.  For example:

HCO~3~^-^

CO~3~^2-^

They "Work For Me (tm)".  Please feel free to fork.  Enjoy!

Shane

Re: [Python-markdown-discuss] Missing imports from extensions/__init__.py

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

Thanks for the report.  I just pushed a fix for this and added tests
to make sure we are generating the correct errors when we are supposed
to.

2010/7/16 Pascal Jürgens <lis...@go...>:
> Hi,
> this is on a current (today) clone from gitorious.
>
> When trying to run a crippled extension of mine, I noticed that the
> Exception was off: Instead of a MarkdownException I got a NameError.
> It seems that __init__.py needs:
>
> from markdown.md_logging import message
> from logging import DEBUG, INFO, WARN, ERROR, CRITICAL
>
> for the load_extension method?
> Cheers,
> Pascal
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>
>



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

[Python-markdown-discuss] Missing imports from extensions/__init__.py

[Pascal J. <lis...@go...>]

Hi,

this is on a current (today) clone from gitorious.

When trying to run a crippled extension of mine, I noticed that the Exception was off: Instead of a MarkdownException I got a NameError.

It seems that __init__.py needs:

> from markdown.md_logging import message
> from logging import DEBUG, INFO, WARN, ERROR, CRITICAL

for the load_extension method?

Cheers,
Pascal

Re: [Python-markdown-discuss] Python 3.0 and 3.1 support

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

>> A) Drop support for 3.0 (but keep supporting 3.1) as the Python
>> project itself has dropped support for 3.0 immediately upon release of
>> 3.1.

I agree. Dropping support for 3.0 is probably the best thing to do.

  - yuri

Re: [Python-markdown-discuss] Python 3.0 and 3.1 support

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

On Tue, Jul 13, 2010 at 12:25 AM, Waylan Limberg <wa...@gm...> wrote:
[snip]
> A) Drop support for 3.0 (but keep supporting 3.1) as the Python
> project itself has dropped support for 3.0 immediately upon release of
> 3.1.
[snip]

Finally found the link to support my claim regarding the support of 3.0:

http://mail.python.org/pipermail/python-list/2009-July/1210690.html

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

[Python-markdown-discuss] Python 3.0 and 3.1 support

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

As part of our support for Python 3.0 we have the following code in
markdown/inlinepatterns.py:

    if sys.version >= "3.0":
        from html import entities as htmlentitydefs
    else:
        import htmlentitydefs

We had to do this because of a bug in the 2to3 tool which shipped with
Python 3.0 where is failed to fix the import.  This bug was fixed with
Python 3.1 and its 2to3 tool makes the following changes:

    import sys
    if sys.version >= "3.0":
        from html import entities as htmlentitydefs
    else:
    -    import htmlentitydefs
    +    import html.entities


    def build_inlinepatterns(md_instance, **kwargs):
    @@ -378,7 +378,7 @@

             def codepoint2name(code):
                 """Return entity definition by code, or the code if
not defined."""
    -            entity = htmlentitydefs.codepoint2name.get(code)
    +            entity = html.entities.codepoint2name.get(code)
                 if entity:
                     return "%s%s;" % (util.AMP_SUBSTITUTE, entity)
                 else:

Of course, the problem is that the import line for pre-3.0 was
changed, but not the import within the version >= 3.0 check. And as
the code that actually uses the library we're importing is changed to
match the new lib name, we are now calling a lib that hasn't actually
been imported. Well actually, I suspect it never gets that far because
it fails with an import error when trying to import the old lib.

So my question is, how should we fix this?

A) Drop support for 3.0 (but keep supporting 3.1) as the Python
project itself has dropped support for 3.0 immediately upon release of
3.1.
B) Fix the imports so that in 3.1 it will import html.entities twice
(silly, but it works)
C) Fix the test to only specifically check for 3.0 (if sys.version == "3.0").

Interestingly, we got a bug report [1] on this when someone ran the
2to3 tool (from Python 3.1), got some errors, looked at the code and
thought it was strange. Only after I figured out this was the order of
events did their report make full sense. If we go with either option B
or C, while we will be avoiding the error, the code will still be just
as confusing to read - although option C seems better in this case.

Personally, I would prefer option A. I remember reading once prior to
the release of Python 3.1 that people should still use 3.1's beta 2to3
tool even when converting to run on Python 3.0. Option A is the only
sensible solution in that scenario. In fact, if someone really needs
markdown on Python 3.0 (perhaps a host won't install 3.1 for some
reason) we can just suggest that they use 3.1's 2to3 tool before
uploading to their host.

Any input?

[1]: http://www.freewisdom.org/projects/python-markdown/Tickets/000066

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

Re: [Python-markdown-discuss] Changes to make it easier to bundle markdown

[Toshio K. <a.b...@gm...>]

On Mon, Jul 05, 2010 at 09:47:59PM -0400, Waylan Limberg wrote:
> On Mon, Jul 5, 2010 at 2:43 PM, Toshio Kuratomi <a.b...@gm...> wrote:
> [snip]
> > I have a patch here that seems to work:
> > http://gitorious.org/python-markdown/toshios-mainline/commit/b50560edc707241b236f9d6c3f33edcf09d7cf33
> >
> 
> Thanks for the feedback.  We are always looking for ways to make
> python-markdown better.
> 
> I'm not so sure about your move of things to misc.  Personally, I
> wonder why not "util", but that's just bike shedding.
>
Branch updated to use "util".  I also noticed that I hadn't committed the
files where I moved the global variables.  They're in there now.

Made a merge request but I can still update it if you want something else
added like renaming misc_logging.py to logging_util.py.

http://gitorious.org/python-markdown/mainline/merge_requests/6

-Toshio

Re: [Python-markdown-discuss] Changes to make it easier to bundle markdown

[Toshio K. <a.b...@gm...>]

On Mon, Jul 05, 2010 at 09:47:59PM -0400, Waylan Limberg wrote:
> On Mon, Jul 5, 2010 at 2:43 PM, Toshio Kuratomi <a.b...@gm...> wrote:
> [snip]
> > I have a patch here that seems to work:
> > http://gitorious.org/python-markdown/toshios-mainline/commit/b50560edc707241b236f9d6c3f33edcf09d7cf33
> >
> 
> Thanks for the feedback.  We are always looking for ways to make
> python-markdown better.
> 
> I'm not so sure about your move of things to misc.  Personally, I
> wonder why not "util", but that's just bike shedding.
> 
Sure, that's not an issue at all :-)
Would you also like misc_logging renamed to something like logging_util.py?

> What really concerns me is that there are a number of third party
> extensions which import these things.  Many of these extensions have
> never been published publicly and we have promised that they will
> continue to work.  So my question is, will these changes only require
> a small adjustment in an import line, or more work.  And if they do
> require just the change in the import line, will the extension only be
> able to work on either one version of markdown or the other?
> 
I think we can make this compatible by adding two lines in my changes.
In __init__.py:

  from misc import *
  from misc_logging import *

This doesn't reintroduce a cyclic dependency because we're still doing
importing things in misc into __init__.py; not importing things in
__init__.py into other parts of the package.

> In fact, a number of the things you've moved to misc, I had intended
> to most to a util file.  But I never got to it before the release of
> 2.0 and now I've considered us stuck with things the way they are for
> the above reasons.  However, if you can convince me that that will not
> be a problem, then I will gladly merge such a change.
> 
> However, regarding the global variables.  Most of those do not need to
> be global variables, but properties on an instance of the Markdown
> class.  In fact, this will also make it easier for users and/or
> extensions to override with their own settings. I've been meaning to
> do this.  However, the few that do need to be global variables, I
> don't see why they can't stay where they are.
> 
I do agree that setting things as class variables would be better :-)

> Personally, I find it strange that you would need to ship markdown
> inside your package.  Why can't markdown be a separate library in it's
> own namespace? That way users can upgrade to newer versions without
> waiting for you to. Sure, I realize you may be offering wrappers and
> want to offer a compatibility guarantee, but I'd personally prefer the
> option of stepping outside that if I wanted. But maybe that's just me.
> 
Oh, I definitely agree here :-)  I'm a packager for Fedora Linux and we're
constantly fighting against bundled libraries for a huge variety of
troublesome issues.  What I hear from upstreams, though, is that they want
to offer users something that works out of the box.  For them that means
shipping with a bundled version of the libraries they depend on.

So what I generally end up having to do is allow upstream to keep their
bundled copy but change their imports so that they first try to import from
a spearate library and if that's not found, fallback to the version that
they have bundled.  This is what I've been attempting to do with webhelpers
(which currently bundles 1.7.0).

-Toshio

Re: [Python-markdown-discuss] Changes to make it easier to bundle markdown

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

On Mon, Jul 5, 2010 at 2:43 PM, Toshio Kuratomi <a.b...@gm...> wrote:
[snip]
> I have a patch here that seems to work:
> http://gitorious.org/python-markdown/toshios-mainline/commit/b50560edc707241b236f9d6c3f33edcf09d7cf33
>

Thanks for the feedback.  We are always looking for ways to make
python-markdown better.

I'm not so sure about your move of things to misc.  Personally, I
wonder why not "util", but that's just bike shedding.

What really concerns me is that there are a number of third party
extensions which import these things.  Many of these extensions have
never been published publicly and we have promised that they will
continue to work.  So my question is, will these changes only require
a small adjustment in an import line, or more work.  And if they do
require just the change in the import line, will the extension only be
able to work on either one version of markdown or the other?

In fact, a number of the things you've moved to misc, I had intended
to most to a util file.  But I never got to it before the release of
2.0 and now I've considered us stuck with things the way they are for
the above reasons.  However, if you can convince me that that will not
be a problem, then I will gladly merge such a change.

However, regarding the global variables.  Most of those do not need to
be global variables, but properties on an instance of the Markdown
class.  In fact, this will also make it easier for users and/or
extensions to override with their own settings. I've been meaning to
do this.  However, the few that do need to be global variables, I
don't see why they can't stay where they are.

Personally, I find it strange that you would need to ship markdown
inside your package.  Why can't markdown be a separate library in it's
own namespace? That way users can upgrade to newer versions without
waiting for you to. Sure, I realize you may be offering wrappers and
want to offer a compatibility guarantee, but I'd personally prefer the
option of stepping outside that if I wanted. But maybe that's just me.

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

[Python-markdown-discuss] Changes to make it easier to bundle markdown

[Toshio K. <a.b...@gm...>]

Hi,  I've been working on getting python-webhelpers copy of markdown updated
to a more recent version and found that the cyclic imports in the code were
making it hard to do so.  Would you take a patch to break the cyclic import?


The current cycles work like this:

  import markdown => imports (blockparser, blockprocessors, inlinparser, etc)
    => import markdown

When markdown is a subpackage, this fails:

  >>> from webhelpers import markdown
  Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "webhelpers/markdown/__init__.py", line 161, in <module>
      import preprocessors
  File "webhelpers/markdown/preprocessors.py", line 11, in <module>
      import webhelpers.markdown as markdown
  AttributeError: 'module' object has no attribute 'markdown'

Moving a portion of the code from markdown into some new files breaks the
cyclic import and allows this to work:

  import markdown => imports blockparser => imports misc

I have a patch here that seems to work:
http://gitorious.org/python-markdown/toshios-mainline/commit/b50560edc707241b236f9d6c3f33edcf09d7cf33

If the idea behind this seems acceptable, I'll propose it for merging.

-Toshio

Re: [Python-markdown-discuss] Can't import COMMAND_LINE_LOGGING_LEVEL

[Jan E. M. <li...@mo...>]

On Wed, Jun 30, 2010 at 18:20, Waylan Limberg <wa...@gm...> wrote:
> It occurs to me that you may not have uninstalled an older version
> before installing the new one.  The problem is that when the
> commandline script is named "markdown.py" it will only ever try to
> import itself rather than the markdown library.  There are solutions
> available to reconfigure your system to not have this problem
> (fiddling with the PYTHONPATH), but that is not something we should
> expect our users to do. The solution we used instead was to rename the
> commandline script by dropping the ".py".  I'm guessing that because
> you did not uninstall the older version, "markdown.py" is still in
> your bin and will still raise the error. First check that
> "/usr/local/bin/markdown" exists, then delete the older script at
> "/usr/local/bin/markdown.py" and just remember to use "markdown" from
> now on.

Thanks, that worked.

- jem

Re: [Python-markdown-discuss] Can't import COMMAND_LINE_LOGGING_LEVEL

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

It occurs to me that you may not have uninstalled an older version
before installing the new one.  The problem is that when the
commandline script is named "markdown.py" it will only ever try to
import itself rather than the markdown library.  There are solutions
available to reconfigure your system to not have this problem
(fiddling with the PYTHONPATH), but that is not something we should
expect our users to do. The solution we used instead was to rename the
commandline script by dropping the ".py".  I'm guessing that because
you did not uninstall the older version, "markdown.py" is still in
your bin and will still raise the error. First check that
"/usr/local/bin/markdown" exists, then delete the older script at
"/usr/local/bin/markdown.py" and just remember to use "markdown" from
now on.

On a somewhat related note, a bug report has been filed with Ubuntu
[1] because both the python and perl implementations of markdown use
"markdown" as their commandline script which creates a conflict.  So
we will be changing the commandline script name again in the next
release. Sigh!   Unless someone has a better suggestion, we'll use
"markdown-python" as that will show up in autocompletion if one types
"markdown".

[1]: https://bugs.launchpad.net/bugs/593565

On Wed, Jun 30, 2010 at 11:35 AM, Jan Erik Moström <li...@mo...> wrote:
> I just tried installing this version but get the same result, this is
> on OS X 10.6.4 - standard install. The python version is 2.6.1, the
> version in /Library/Python/2.6/site-packages/markdown is 2.0.3 (I've
> tried logging in/out etc).
>
> Any advice on how to proceed is most welcome.
>
> - jem
>
> On Wed, Jun 30, 2010 at 16:57, Waylan Limberg <wa...@gm...> wrote:
>> It would appear that you have installed an older version which had
>> this problem on some systems depending on how they are configured.
>>
>> The latest version (currently 2.0.3)  is here:
>> http://pypi.python.org/pypi/Markdown
>>
>> On Wed, Jun 30, 2010 at 9:23 AM, Jan Erik Moström <li...@mo...> wrote:
>>> I just installed python markdown and tried to run it and got the
>>> following message
>>>
>>>  File "/usr/local/bin/markdown.py", line 44, in <module>
>>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>>  File "/usr/local/bin/markdown.py", line 44, in <module>
>>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>>>
>>> Does anyone have an idea what I missed during install?
>>>
>>> - jem
>



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

Re: [Python-markdown-discuss] Can't import COMMAND_LINE_LOGGING_LEVEL

[Jan E. M. <li...@mo...>]

I just tried installing this version but get the same result, this is
on OS X 10.6.4 - standard install. The python version is 2.6.1, the
version in /Library/Python/2.6/site-packages/markdown is 2.0.3 (I've
tried logging in/out etc).

Any advice on how to proceed is most welcome.

- jem

On Wed, Jun 30, 2010 at 16:57, Waylan Limberg <wa...@gm...> wrote:
> It would appear that you have installed an older version which had
> this problem on some systems depending on how they are configured.
>
> The latest version (currently 2.0.3)  is here:
> http://pypi.python.org/pypi/Markdown
>
> On Wed, Jun 30, 2010 at 9:23 AM, Jan Erik Moström <li...@mo...> wrote:
>> I just installed python markdown and tried to run it and got the
>> following message
>>
>>  File "/usr/local/bin/markdown.py", line 44, in <module>
>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>>  File "/usr/local/bin/markdown.py", line 44, in <module>
>>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>>
>> Does anyone have an idea what I missed during install?
>>
>> - jem

Re: [Python-markdown-discuss] Can't import COMMAND_LINE_LOGGING_LEVEL

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

It would appear that you have installed an older version which had
this problem on some systems depending on how they are configured.

The latest version (currently 2.0.3)  is here:
http://pypi.python.org/pypi/Markdown

On Wed, Jun 30, 2010 at 9:23 AM, Jan Erik Moström <li...@mo...> wrote:
> I just installed python markdown and tried to run it and got the
> following message
>
>  File "/usr/local/bin/markdown.py", line 44, in <module>
>    from markdown import COMMAND_LINE_LOGGING_LEVEL
>  File "/usr/local/bin/markdown.py", line 44, in <module>
>    from markdown import COMMAND_LINE_LOGGING_LEVEL
> ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL
>
> Does anyone have an idea what I missed during install?
>
> - jem
>
> ------------------------------------------------------------------------------
> This SF.net email is sponsored by Sprint
> What will you do first with EVO, the first 4G phone?
> Visit sprint.com/first -- http://p.sf.net/sfu/sprint-com-first
> _______________________________________________
> Python-markdown-discuss mailing list
> Pyt...@li...
> https://lists.sourceforge.net/lists/listinfo/python-markdown-discuss
>



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

[Python-markdown-discuss] Can't import COMMAND_LINE_LOGGING_LEVEL

[Jan E. M. <li...@mo...>]

I just installed python markdown and tried to run it and got the
following message

  File "/usr/local/bin/markdown.py", line 44, in <module>
    from markdown import COMMAND_LINE_LOGGING_LEVEL
  File "/usr/local/bin/markdown.py", line 44, in <module>
    from markdown import COMMAND_LINE_LOGGING_LEVEL
ImportError: cannot import name COMMAND_LINE_LOGGING_LEVEL

Does anyone have an idea what I missed during install?

- jem