python-markdown-discuss — A general purpose discussion list

Re: [Python-markdown-discuss] python-markdown, and wikis.

[Herbert P. <her...@gm...>]

hi,

On Feb 5, 2008 5:37 AM, Waylan Limberg <wa...@gm...> wrote:
> I'm aware of a few. There's one I don't remember the name of that has
> added all sorts of ridiculous (IMHO) macros to the syntax. All I
> remember is that it's built on the Django framework.

do you by any chance mean my wiki: SCT - http://sct.sphene.net/
if you think {macroname parameter=value} is weird .. it's probably it ;)
http://sct.sphene.net/wiki/show/WikiDocumentation/

although .. i don't know why the syntax should be weird ;) i actually
copied it from another wiki engine i've used in the java world
(radeox)
the nice thing about it is that it makes it very easy to add addtional
macros: http://yourhell.com/wsvn/root/django/communitytools/trunk/sphenecoll/sphene/sphwiki/wikimacros.py
.. without dealing with strings or anything ..

anyway ... i'm simpy using the (slightly modified) wikilink extension
for python-markdown: http://achinghead.com/markdown/wikilink/


cu,
  herbert

> Another django
> wiki, which I'm quite impressed with is monk-wiki[1], although its
> still in development. The source code is available though.
>
> I've copied the list[2]. Perhaps others will be able to point you to
> some more. Please let us know what you come up with. I'm been
> interested in building a wiki that uses markdown for some time. I just
> haven't had the spare time.
>
> [1]: http://code.google.com/p/monk-wiki/
> [2]: http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss
>
> >
> > Oh, and do you handle definition lists?  The examples I saw were all of
> > the form:
> >
> > definition term
> > :  definition description
> >
> > If you don't handle them, how hard do you think it would be to create a
> > plugin that would handle them?
> >
>
> Unfortunately, that's the one thing I haven't tried to tackle yet. I
> find the whole 'description gets the markup (:), not the term' a
> little hard to wrap my mind around. I keep getting the feeling that
> we'll need to make some changes to the core to get that one to work,
> although I could be wrong. If you have any suggestions, I'm game.
>
>
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
> -------------------------------------------------------------------------
> 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
>

Re: [Python-markdown-discuss] python-markdown, and wikis.

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

Blake,

On Feb 4, 2008 7:50 PM, Blake Winton <bw...@la...> wrote:
> Hi,
>
> uh, you don't know me, but I'm investigating switching a home-grown wiki
> parser over to use Markdown syntax instead.  Since everything else is
> written in Python, I'm mainly considering python-markdown and
> python-markdown2.  I think you guys have the edge in terms of my being
> able to add wiki links, and generically extend it,

I'd say you nailed it. That about sums up the difference. With
python-markdown2, you'd need to hack the core to add or change
behavior. Personally, I'd much rather use python-markdown's extension
api. In fact if you run into a few dead ends, let us know. We may be
able to improve the api to make more things possible.

> but I was wondering
> if you had any suggestions of wikis that were using your project?

I'm aware of a few. There's one I don't remember the name of that has
added all sorts of ridiculous (IMHO) macros to the syntax. All I
remember is that it's built on the Django framework. Another django
wiki, which I'm quite impressed with is monk-wiki[1], although its
still in development. The source code is available though.

I've copied the list[2]. Perhaps others will be able to point you to
some more. Please let us know what you come up with. I'm been
interested in building a wiki that uses markdown for some time. I just
haven't had the spare time.

[1]: http://code.google.com/p/monk-wiki/
[2]: http://sourceforge.net/mailarchive/forum.php?forum_name=python-markdown-discuss

>
> Oh, and do you handle definition lists?  The examples I saw were all of
> the form:
>
> definition term
> :  definition description
>
> If you don't handle them, how hard do you think it would be to create a
> plugin that would handle them?
>

Unfortunately, that's the one thing I haven't tried to tackle yet. I
find the whole 'description gets the markup (:), not the term' a
little hard to wrap my mind around. I keep getting the feeling that
we'll need to make some changes to the core to get that one to work,
although I could be wrong. If you have any suggestions, I'm game.





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

Re: [Python-markdown-discuss] replacing " with &quot;

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

Thanks for the feedback guys. I just wanted to make sure I wasn't
missing anything before commiting the change. Oh, and Michel, thanks
for the reminder about attributes. Python-markdown's dom should make
that easy to do.

On Jan 5, 2008 10:29 AM, Yuri Takhteyev <qar...@gm...> wrote:
> I agree with Michel, that it's better to not escape things where it's
> not necessary.
>
> If you want to fix it, the place to do is the method
> Document.normalizeEntities(), which is now called in two places:
>
> 1. in Element.toxml() separately for each attribute
> 2. in TextNode.toxml() for the whole thing
>
> The quickest fix would be to add an extra keyword parameter to this
> function: something like "skip_quotes" and call with this parameter in
> the second case.  Note that "<", ">", and "&" need to be replaced in
> both cases.
>
>   - yuri
>
> On Jan 5, 2008 4:51 AM, Michel Fortin <mic...@mi...> wrote:
>
> > > So, my question is: Which implementation do you consider correct
> > > and why?
> >
> > I'd say both are correct since, within HTML or XML character data, a
> > character entity is semantically equivalent to the litteral character
> > it represents. But for the sake of compatibility with other
> > processing tools, I'd avoid using an entity for strait quotes (or any
> > other character for that matter) when it's not necessary.
>
> --
> http://sputnik.freewisdom.org/
>
> _______________________________________________
> Markdown-Discuss mailing list
> Mar...@si...
> http://six.pairlist.net/mailman/listinfo/markdown-discuss
>



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

[Python-markdown-discuss] replacing " with &quot;

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

Python-markdown currently replaces all straight quotes (`"`) with the
html entity (`"`). Someone recently complained about this in a
[bug report][]. As it turns out the quote was the symptom that brought
the real problem to light[^1]. In any event, the reporter pointed out
that markdown.pl does not replace straight quotes with the html
entity. I know John Gruber has mentioned before that just because
markdown.pl does something, doesn't mean it's right, but the more I
think about it the more I think this is right.

1. First of all, using the straight quote is not invalid html or
xhtml, so why do we care? In fact, I can't seem to find one reference
that explains why the html entity should be used in this case.

2. If I'm not mistaken, having markdown output the html entity makes
it imposable for smartypants to then convert straight quotes into
"curly" quotes - which may be undesirable to some users.

So, my question is: Which implementation do you consider correct and why?

[bug report]: https://sourceforge.net/tracker/index.php?func=detail&aid=1862742&group_id=153041&atid=790198

[^1]: The reporter was running Django template syntax through
markdown. As the quotes were all converted to entities, he no longer
had valid template syntax. Of course, the real problem is that the
template syntax should be treated like raw html and python-markdown's
extension api makes that easy to do. Otherwise you'd get a tag soup of
various blocks of syntax wrapped in unwanted paragraphs and other such
undesirable results.

Of interest to me is that this is the second bug report we've
(python-markdown) received in less than a week because people are
running documents with template syntax through markdown (the other
reporter was using Mako). I had never considered this use case before
(although Yuri apparently has) and me knee-jerk reaction was to not
care and suggest that they use raw html in their templates. Is this
really a common use case?
-- 
----
Waylan Limberg
wa...@gm...

Re: [Python-markdown-discuss] Not liking Mako-like syntax

[Aaron G. <fl...@sh...>]

Thanks Yuri and Waylan for the explanations. Especially thanks for the  
code change that's got me able to resume work on my project!

Aaron Gyes

Re: [Python-markdown-discuss] Not liking Mako-like syntax

[Yuri T. <yu...@cs...>]

On Dec 31, 2007 10:49 AM, Waylan Limberg <wa...@gm...> wrote:
> Well,  the proper way would be to write your own pre-processor that
> strips out all the mako markup and adds it to the htmlstash. That is,
> after all, how html is currently ignored (in HtmlBlockPreprocessor -
> line 486).
>
> With only a quick look, my guess is that the problem stems from the
> fact that python-markdown has a very limited understanding of xml.
> Therefore, the `%`s are throwing it off. In fact, if you try your
> given test case without the `%` it works fine:

First, for the record, <%foo /> doesn't count as XML.  Second, yes,
the _right_ way to do this is to write a custom preprocessor.

However, my intension was to support this, so I suppose this is a bug.
 Let me explain how it is _supposed_ to work:

When the script encounters an HTML tag in the beginning of the block,
it classifies the tag into three types:

1. Tags that open an HTML block, such as <table> or <pre>.  In this
case, there will be no markdown processing until the block is closed
with the same tag.  There will also be no "<p>..</p>" around this
chunk of html.
2. Tags like <div> or <?php>.  In this case we don't look for the
closing tag, but we also avoid putting <p>...</p> around the block.
3. Inline tags.  We don't look for where the tag closes and we put
<p>...</p> around the block.

#2 is supposed to include "div", as well as any tags starting with
"%", "?".  The rationale is that for something like <?php> or <%foo>
we don't really know what that tag means and we don't want to make any
assumption as to whether it needs to be closed _or_ whether it needs
<p> around it.  If you want "<p>" around your <%foo/>, you can put it
manually, after all, but you won't be able to remove it easily if we
add it.

So, "%foo" and "foo" are supposed to be treated differently.
"<foo>**bar**" should become "<p><foo><b>bar</b><p>" while
"<%foo>**bar**" is supposed to become as "<%foo><b>bar</b>"

It obviously doesn't work that way.  I think that the bug is either
_get_right_tag() or _equal_tag().  The quick fix is to change line 499
to

        if left_tag in ['div'] or left_tag[0] in ["?", "@", "%"]: #
handle PHP, etc.

Though, at some point, the whole HTML_Block_Preprocessor logic needs
to be rethought.  It seems more convoluted than it needs to be.

I hope this helps.

- yuri

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

Re: [Python-markdown-discuss] Not liking Mako-like syntax

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

Well,  the proper way would be to write your own pre-processor that
strips out all the mako markup and adds it to the htmlstash. That is,
after all, how html is currently ignored (in HtmlBlockPreprocessor -
line 486).

With only a quick look, my guess is that the problem stems from the
fact that python-markdown has a very limited understanding of xml.
Therefore, the `%`s are throwing it off. In fact, if you try your
given test case without the `%` it works fine:

    <foo />

    Heading
    ======

For a quick and dirty hack you could just add a special condition to
check for `%` (similar to the check for html comments) right in
HtmlBlockPreprocessor. However, I doubt that would ever make it into
the distribution [^1]. After all, there are various non-xml based
template languages which would still not be supported. That said, it
wouldn't hurt to at least explore the possibility of better xml
parsing. That, however, is another issue for another time. And that is
why the proper approach is to write your own extension with a
preprocessor that strips the markup for your preferred template
language.

[^1]: I realize that other markdown implementation may currently work
with mako syntax. However, I believe it likely that that is an
unexpected side affect of the way their respective html/xml parsers
are implemented rather than a specific feature that was intentionally
built in. That being the case, any code specifically to address one
single template language's syntax belongs in an extension rather than
markdown proper.

On Dec 31, 2007 1:16 AM, Aaron Gyes <fl...@sh...> wrote:
> Thanks!
>
> If anyone has any ideas for a quick-and-dirty hack to make in
> markdown.py to make it act normal I would really appreciate it. I
> played around for 20 minutes never got anywhere! I think maybe it's
> not exactly in the _get_right_tag, it seems that something before that
> part is acting different. `block` contains stuff I don't see if  it
> were to be going over something like <foo />.
>
> Aaron
>
>
> On Dec 30, 2007, at 7:45 PM, Waylan Limberg wrote:
>
> > Thanks for the report Aaron. I see you reported this in the bug
> > tracker too - which will make sure we don't forget it. I'll look into
> > this when I get a chance.
> >
> > On Dec 30, 2007 6:04 AM, Aaron Gyes <fl...@sh...> wrote:
> >> Hi,
> >>
> >> I was looking to use this markdown module (the 1.7RC1 at the moment)
> >> on some strings that also have mako template tags in them. They
> >> basically look like this:
> >>
> >> <%def .... />
> >> <%page .... />
> >> % for x in foo:
> >> ...
> >> % endfor
> >>
> >> Anyways, I figured I might need to do something special for the
> >> strange '%' flow control structures, but I assumed that like the
> >> other
> >> markdown implementations it would ignore the other stuff like HTML
> >> tags, but it's totally choking. Here's a "test case":
> >>
> >> <%foo />
> >>
> >> Heading
> >> =======
> >>
> >>
> >> Simply returns the entire thing as-is. I'm guessing it never thought
> >> whatever kind of tag that was there ended up closing.
> >>
> >> Can I fix this through the API somehow?
> >>
> >> Aaron Gyes
> >>
> >> -------------------------------------------------------------------------
> >> This SF.net email is sponsored by: Microsoft
> >> Defy all challenges. Microsoft(R) Visual Studio 2005.
> >> 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...
>



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

Re: [Python-markdown-discuss] Not liking Mako-like syntax

[Aaron G. <fl...@sh...>]

Thanks!

If anyone has any ideas for a quick-and-dirty hack to make in  
markdown.py to make it act normal I would really appreciate it. I  
played around for 20 minutes never got anywhere! I think maybe it's  
not exactly in the _get_right_tag, it seems that something before that  
part is acting different. `block` contains stuff I don't see if  it  
were to be going over something like <foo />.

Aaron

On Dec 30, 2007, at 7:45 PM, Waylan Limberg wrote:

> Thanks for the report Aaron. I see you reported this in the bug
> tracker too - which will make sure we don't forget it. I'll look into
> this when I get a chance.
>
> On Dec 30, 2007 6:04 AM, Aaron Gyes <fl...@sh...> wrote:
>> Hi,
>>
>> I was looking to use this markdown module (the 1.7RC1 at the moment)
>> on some strings that also have mako template tags in them. They
>> basically look like this:
>>
>> <%def .... />
>> <%page .... />
>> % for x in foo:
>> ...
>> % endfor
>>
>> Anyways, I figured I might need to do something special for the
>> strange '%' flow control structures, but I assumed that like the  
>> other
>> markdown implementations it would ignore the other stuff like HTML
>> tags, but it's totally choking. Here's a "test case":
>>
>> <%foo />
>>
>> Heading
>> =======
>>
>>
>> Simply returns the entire thing as-is. I'm guessing it never thought
>> whatever kind of tag that was there ended up closing.
>>
>> Can I fix this through the API somehow?
>>
>> Aaron Gyes
>>
>> -------------------------------------------------------------------------
>> This SF.net email is sponsored by: Microsoft
>> Defy all challenges. Microsoft(R) Visual Studio 2005.
>> 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...

Re: [Python-markdown-discuss] Not liking Mako-like syntax

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

Thanks for the report Aaron. I see you reported this in the bug
tracker too - which will make sure we don't forget it. I'll look into
this when I get a chance.

On Dec 30, 2007 6:04 AM, Aaron Gyes <fl...@sh...> wrote:
> Hi,
>
> I was looking to use this markdown module (the 1.7RC1 at the moment)
> on some strings that also have mako template tags in them. They
> basically look like this:
>
> <%def .... />
> <%page .... />
> % for x in foo:
> ...
> % endfor
>
> Anyways, I figured I might need to do something special for the
> strange '%' flow control structures, but I assumed that like the other
> markdown implementations it would ignore the other stuff like HTML
> tags, but it's totally choking. Here's a "test case":
>
> <%foo />
>
> Heading
> =======
>
>
> Simply returns the entire thing as-is. I'm guessing it never thought
> whatever kind of tag that was there ended up closing.
>
> Can I fix this through the API somehow?
>
> Aaron Gyes
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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] Not liking Mako-like syntax

[Aaron G. <fl...@sh...>]

Hi,

I was looking to use this markdown module (the 1.7RC1 at the moment)  
on some strings that also have mako template tags in them. They  
basically look like this:

<%def .... />
<%page .... />
% for x in foo:
...
% endfor

Anyways, I figured I might need to do something special for the  
strange '%' flow control structures, but I assumed that like the other  
markdown implementations it would ignore the other stuff like HTML  
tags, but it's totally choking. Here's a "test case":

<%foo />

Heading
=======


Simply returns the entire thing as-is. I'm guessing it never thought  
whatever kind of tag that was there ended up closing.

Can I fix this through the API somehow?

Aaron Gyes

[Python-markdown-discuss] Markdown Version 1.7 - Release candidate 1

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

Release Candidate 1 of Markdown version 1.7 for is now available for
community review. Dowload from here[1].

[1]: http://downloads.sourceforge.net/python-markdown/python_markdown-1.7.rc1.zip

See CHANGE_LOG.txt for the changes. Please report any problems either
here or on the tracker.

Note that various features marked as depreciated in 1.6 have been
removed, so this release is somewhat backward incompatible. Most
notably, `str(md)` will no longer work. `md.convert(text)` should be
used instead. The `toString` and `toUnicode` methods no longer exist.
The `__unicode__` method calls `convert` and `__str__` returns some
info about the instance rather than the converted output (although I'm
open for suggestions for improvment in the info provided). Additionally,
the `encoding` argument has been removed from both `markdown` and
`Markdown`. Markdown expects unicode (or ascii) input and it is the
users responsibility to ensure that's what is provided. Therefore, all
output is in unicode. Only `markdownFromFile` accepts an encoding.

Happy testing!

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

Re: [Python-markdown-discuss] [ Bug-1844795 ] Escaped links and emphasised links

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

Below is a recent bug report and my response. Any input on either
issue would be appreciated, although, I'm mostly looking for an answer
to the question I ask on the first issue in my response:

Would we prefer emphasis inside links or links inside emphasis? In
other words, which is more likely to be used:

    [_emphasised link_][1]

or

    _A [link][2] inside emphasis_

Something I didn't mention is that I have no idea if moving the
emphasis patterns before link patterns would create a whole bunch of
other issues. So, this may not be doable anyway.

On Dec 6, 2007 12:16 AM, SourceForge.net <no...@so...> wrote:
> Bugs item #1844795, was opened at 2007-12-05 07:52
> Message generated for change (Comment added) made by waylanhl
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=790198&aid=1844795&group_id=153041
>
> Please note that this message will contain a full copy of the comment thread,
> including the initial issue submission, for this request,
> not just the latest update.
> Category: Difference from Perl Version
> Group: Markdown Core
> Status: Open
> Resolution: None
> Priority: 5
> Private: No
> Submitted By: Matt Godbolt (matt-godbolt)
> Assigned to: Nobody/Anonymous (nobody)
> Summary: Escaped links and emphasised links format differently
>
> Initial Comment:
> If you format code such as:
>
> """
>
> The following paragraph should be emphasised:
>
> _A link [inside][] an emphasis._
>
> The following should be rendered as a link:
>
> A link with underscores : [\_set\_sbh\_threshold][setsbh].
>
> [inside]: http://www.google.com/ "Google"
> [setsbh]: http://msdn.microsoft.com/library/default.asp?url=/library/en-us/vclib/html/_crt__set_sbh_threshold.asp "Set Small Object Threshold"
>
> """
>
> (NB I have "SMART_EMPHASIS = 0")
>
> The emphasised link line comes out non-emphasised, with the leading and trailing underscores unstripped.
>
> The escaped link fails to be "linked" and comes out exactly as-is.
>
> The Perl version doesn't suffer from this issue, and formats the two lines as you'd expecte: a line with emphasis and a link inside it; and a linked underscored line.
>
> ----------------------------------------------------------------------
>
> >Comment By: waylan (waylanhl)
> Date: 2007-12-06 00:16
>
> Message:
> Logged In: YES
> user_id=1524916
> Originator: NO
>
> Thanks for the report. These are two unrelated issues - sort of.
>
> The 'link in emphasis' issue, is a simple fix - change the order of the
> InlinePatterns so that emphasis is run before links, but then we lose the
> ability to have emphasis inside links. It's a trade-off, we get one or the
> other and I'm not sure which is more desirable.
>
> The escaping issue is a little more complex (and also is the reason the
> recent addition of recursion in the inlinePatterns doesn't address the
> first issue). The ESCAPE_PATTERN is the first pattern run, which removes
> the backslash and inserts the character immediately following (the
> underscore in this case) into the dom as a TextNode. The problem is that
> the link is now spread across multiple nodes and there is no way to run a
> pattern against it. As markdown.pl doesn't use a dom, this is a non-issue
> for it. To add insult to injury, prior to adding recursion to
> inlinePatterns, there would have been no need to escape that link and
> things would have worked fine. The emphasis pattern would have never been
> run against that text. However, it would have still failed if escaped.
>
> Perhaps escaping needs to be addressed in a completely different manner.
>
> Although that doesn't address the first issue. The extreme solution would
> be to drop/alter the use of the dom, but that would be a **major**  and
> very unlikely change - at least in the foreseeable future.
>
> I'll take this to the list for input.
>
>
>
> ----------------------------------------------------------------------
>
> You can respond by visiting:
> https://sourceforge.net/tracker/?func=detail&atid=790198&aid=1844795&group_id=153041
>



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

Re: [Python-markdown-discuss] Announcing Apydia

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

FYI, here's my response as posted on the Apydia list:

On Nov 30, 2007 1:26 PM, Waylan Limberg <wa...@gm...> wrote:
> First, as one of the core markdown devs, I'd like to say that I'm
> excited to see support for markdown. That has been an itch I've wanted
> scratched for some time.
>
> To add to that, I see you are also using a stripped down version of my
> CodeHilite extension for markdown. That's excellent! I've been
> debating weather I should do the same to the extension. I first
> started that extension before Pygments (even before there was an
> extension api for markdown), so all the non-pygments stuff came first.
> When I first discovered pygments, I just added it into the existing
> api. Now I don't see any need for the other stuff.
>
> Anyway, I have never received any feedback on the syntax for
> specifying the language used on code blocks. As there is no
> established convention in markdown in general, I came up with my own.
> So, yeah, you probably should document it. Of course, I'm open to
> other/better suggestions.


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

[Python-markdown-discuss] Announcing Apydia

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

Earlier today Apydia was released to the world. Apydia is an API
reference documentation generator for Python that **supports
markdown** (among others) in doc strings.

Needless to say, I'm pretty excited about this even if I had nothing
to do with it. I've already added it to the "related projects" page on
the site. Below is a copy of the full announcement.


---------- Forwarded message ----------
From: Daniel Haus <dan...@gm...>
Date: Nov 30, 2007 5:51 AM
Subject: [elixir] Announcing Apydia
To: SQLElixir <sql...@go...>



Today, I am very excited to announce the first release of the Apydia
API reference documentation generator for Python. It's designed as an
instantly serviceable replacement for Pudge's API documentation
generator. It won't generate complete websites from reST etc. like
Pudge does, though - Apydia is only about the API.

Features include:

- Basic Pudge compatibility and a short and easy migration path
- Rudimentary Trac-integration, that is links into Trac's sourcecode
browser
- Some fair amount of usability
- Setuptools integration
- Flexible, Genshi/XInclude-based themeability with theme inheritance
- Support for various text formats like Markdown, Textile and reST
- Other parsers can easily be plugged in on demand
- Syntax highlighting thanks to Pygments

For more information visit Apydia's web site at http://apydia.ematia.de
and the Apydia Google Group at http://groups.google.com/group/apydia.

--
Daniel Haus
http://ematia.de
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google
Groups "SQLElixir" group.
To post to this group, send email to sql...@go...
To unsubscribe from this group, send email to
sql...@go...
For more options, visit this group at
http://groups.google.com/group/sqlelixir?hl=en
-~----------~----~----~----~------~----~------~--~---




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

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

I've committed a patch (r58) that adds use of the logging module. I
have left the `message` method as a wrapper in case any one's using it
in their extensions.

We gain two more levels (WARN & ERROR) between INFO & CRITICAL. I may
go through the code and add a few more messages to make use of them
when I have the time.

If anyone has any other input/sugestions/critisisms, please share.

The following is some documentation for customization. I'll likely add
a more polished version to the wiki when I have the time.

### Adding Logging Handlers
You could easily add any handler supported by the logging module.
Currently, only StreamHandler (outputs to console via stderr) is being
used. As the message threshold is restricted on the handler and not
the logger, your own handlers can have whatever level you want. The
level set by MESSAGE_THRESHOLD or through command line options only
affect the console output. Therefore, were `myHandler` is a handler of
the type and configuration you want:

    import markdown
    markdown.logger.addHandler(myHandler)
    markdown.markdown(text)

### Logging in Extensions
You could also configure your extension to inherit from markdown's
logger. Markdown's logger is named "MARKDOWN", so logging in an
extension would look something like this:

    import logging
    mylogger = logging.getLogger("MARKDOWN.myextension")

    mylogger.critical('A critical message!')

Then your message would look something like this:

    MARKDOWN.myextension-CRITICAL: "A critical message!"

Notice how the extension name appears in the message, which can be
helpful in debugging.



On Nov 16, 2007 11:35 AM, Waylan Limberg <wa...@gm...> wrote:
> Ok, I've worked out some logging code and tested it in all supported
> versions of python (2.3 is a pain to configure compared to 2.4 & 2.5).
> The question is, do we want to leave the api the same and wrap logging
> in our existing `message` method, or use logging directly? It's no
> trouble to do either. See the attached test file for examples.
>
> Any suggestions/improvements to the message format?
> Currently: NAME-LEVEL: "MESSAGE"
>
> The attached sample outputs the following:
>
>     MARKDOWN-DEBUG: "A debug message"
>     MARKDOWN-INFO: "info message"
>     MARKDOWN-WARNING: "warn message"
>     MARKDOWN-ERROR: "error message"
>     MARKDOWN-CRITICAL: "critical message"
>     MARKDOWN-WARNING: "a warning"
>     MARKDOWN-CRITICAL: "A Message using Markdown's existing api"
>
> I'll also mention that we could define our own levels, but why?
>
>
>
> On Nov 16, 2007 12:52 AM, Yuri Takhteyev <qar...@gm...> wrote:
> > Oh, well, what do we sociologists know...  Sure, let's send it to stderr.
> >
> >   - yuri
> >
> >
> >
> > On Nov 15, 2007 11:25 PM, Waylan Limberg <wa...@gm... > wrote:
> > >
> > > On Nov 15, 2007 9:13 PM, Yuri Takhteyev < qar...@gm...> wrote:
> > > > Not all messages are errors, so they probably shouldn't all go to the
> > error
> > > > stream.  Or should they?
> > >
> > > Yes they should - that's the general convention as I see it. Its a
> > > poorly named status stream. In fact, the logging module sends all
> > > messages (including non-error) to the error stream by default.
> > > Consider this simple commandline example:
> > >
> > > As it goes currently, when we run this command:
> > >
> > >    $ python markdown.py input.txt > output.html
> > >
> > > Any messages will get output to stdout, which in this case is
> > > output.html. However, if all messages are sent to stderr, then they
> > > would display on the console - not in output.html. I would say that is
> > > the desired behavior. I shouldn't have to open the file to see if any
> > > messages were generated.
> > >
> > > In the case of a wsgi app (and by extension most wsgi web frameworks),
> > > anything that would get logged is expected to go to stderr. Stdout is
> > > expected to be disabled. Seeing stderr & stdout are the only two
> > > options we have, stderr is the only acceptable choice here.
> > >
> > > I could be wrong, but I'd say it's also more likely that if output to
> > > the console is not an option, applications of any kind are more likely
> > > to redirect stderr than stdout. So if we use stderr, the messages are
> > > more likely to go were the developers want them to.
> > >
> > >
> > > >
> > > > I think at the time I was thinking in fact of using messages for
> > non-error
> > > > messages and using print_error() for errors.  Now, arguably
> > > > message(CRITICAL, "...") should be interpreted as an error.  Perhaps the
> > > > thing to do is to follow Trent's suggestion and to yank this function
> > out
> > > > altogether and replace with with calls to logging.  Less confusion.
> > >
> > > I forgot about logging, so thanks Trent. Yeah that certainly makes the
> > > most sense. But, just redirecting the current system to stderr would
> > > accomplish the same end. Therefore, I'm inclined to just do the
> > > quickfix now and work on logging for later.
> > >
> > > One additional advantage that logging would give us is that is should
> > > be easier for others to send the messages wherever they want - stderr,
> > > stdout, a log file, a blackhole... Then, when someone finds a
> > > new/different environment to use markdown in, it's easy for them to
> > > get it to work the way they need/want. It defiantly makes sense to use
> > > logging long term.
> > >
> > >
> > >
> > >
> > > >
> > > >   - yuri
> > > >
> > > >
> > > >
> > > >
> > > > On Nov 15, 2007 5:56 PM, Waylan Limberg <wa...@gm... > wrote:
> > > > >
> > > > >
> > > > >
> > > > > I should mention the easy fix. Just have `message` write to
> > `sys.stderr`:
> > > > >
> > > > >      def message(level, text) :
> > > > >          if level >= MESSAGE_THRESHOLD :
> > > > >     -        print text
> > > > >    +        print >> sys.stderr, text          # or
> > > > sys.stderr.write(text+'\n')
> > > > >
> > > > > But, is that good enough or should we use python's built-in
> > > > error-handling?
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > >
> > > > > On Nov 15, 2007 3:35 PM, Waylan Limberg < wa...@gm... > wrote:
> > > > > >
> > > > > > Below is the text of the bug [1] I just filed. The reason I'm
> > posting
> > > > > > here is to get some feedback. Why was it done the way it is? Is
> > there
> > > > > > any good reason not to change?
> > > > > >
> > > > > > [1]:
> > > >
> > http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198
> > > > > >
> > > > > > > Currently, caught errors are handled by the `message` method which
> > > > > > > uses `print` to display error/warning messages. As `print` outputs
> > to
> > > > > > > `sys.stout` by default, this conflicts with the wsgi spec [1].
> > > > > > >
> > > > > > > To my knowledge, wsgi_mod [2] is the only server that enforces the
> > > > > > > spec here, but in doing so, any `message` generated by markdown
> > would
> > > > > > > cause a `500` response by wsgi_mod. As most any python
> > web-framework
> > > > > > > has a wsgi interface, we should expect python-markdown to be used
> > in
> > > > > > > wsgi environments repeatedly and IMO support such use. FYI, I
> > first
> > > > > > > came across the problem here [3].
> > > > > > >
> > > > > > > We could just raise exceptions, but python trackbacks can be ugly
> > > > > > > (especially when were dealing with an end user and markdown syntax
> > > > > > > errors) and we need multiple levels. Perhaps we should be using
> > the
> > > > > > > warnings module [3] (available since Python 2.1) which outputs to
> > > > > > > `sys.stderr` by default.
> > > > > > >
> > > > > > > [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> > > > > > > [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> > > > > > > [3]: http://code.djangoproject.com/ticket/2910#comment:12
> > > > > > > [4]: http://docs.python.org/lib/module-warnings.html
> > > > > >
> > > > > >
> > > > > > --
> > > > > > ----
> > > > > > Waylan Limberg
> > > > > > wa...@gm...
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > ----
> > > > > Waylan Limberg
> > > > > wa...@gm...
> > > > >
> > > > >
> > -------------------------------------------------------------------------
> > > > > This SF.net email is sponsored by: Microsoft
> > > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > > 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
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > Yuri Takhteyev
> > > > Ph.D. Candidate, UC Berkeley School of Information
> > > > http://takhteyev.org/, http://www.freewisdom.org/
> > >
> > >
> > >
> > > --
> > > ----
> > >
> > >
> > >
> > > Waylan Limberg
> > > wa...@gm...
> > >
> >
> >
> >
> > --
> >
> >
> > Yuri Takhteyev
> > Ph.D. Candidate, UC Berkeley School of Information
> > http://takhteyev.org/, http://www.freewisdom.org/
>
>
>
> --
> ----
>
> Waylan Limberg
> wa...@gm...
>



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

Re: [Python-markdown-discuss] Bug 1763338 and Max Recursion

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

Nevermind. This is now fixed in r57. Nested listes were giving me a
few headaches that seemed obvious with recursion, but not with a loop.
I worked them out though.

On Nov 16, 2007 11:20 PM, Waylan Limberg <wa...@gm...> wrote:
> Some time ago I looked at bug 176338 [1] and lowered its priority
> significantly as the sample input was a far cry from markdown syntax.
> I recognized the need for a more graceful way to deal with the issue,
> but given the formatting of the text, it didn't seem all that
> important.
>
> Thing is, now I realize that the sample text attached to that ticket
> was skewing the issue. The bad syntax was just escalating the problem.
> The fact is, the current way `_process_section` works (it recursively
> calls itself on each block of remaining text), we can easily reach max
> recursion with perfectly good syntax.
>
> Therefore, I created a document the following way:
>
>     import sys
>     t = ""
>     for i in range(sys.getrecursionlimit()):
>         t += "Paragraph %d.\n\n" % i
>
> That's 1000 paragraphs one line each - as simple of markdown syntax as
> one could have. Even so:
>
>     html = markdown.markdown(t)
>     ...
>     RuntimeError: maximum recursion depth exceeded
>
> I played with a few different numbers and 985 was the magic number.
> The maximum paragraphs a markdown document can have is 984. That's
> assuming no lists, blockquotes or anything else that necessarily goes
> deeper into recursion.
>
> While replacing recursion with a loop is probably easier said than
> done, do we care? In other words, are we ok limiting the possible
> length of documents we can process - with that limit becoming shorter
> the more complex the syntax used?
>
> If so, I'll just catch the exception and output a friendlier message.
>
> If not, we may have some work to do - although I'd suggest not holding
> up 1.7 for it.
>
> [1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1763338&group_id=153041&atid=790198
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



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

[Python-markdown-discuss] Bug 1763338 and Max Recursion

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

Some time ago I looked at bug 176338 [1] and lowered its priority
significantly as the sample input was a far cry from markdown syntax.
I recognized the need for a more graceful way to deal with the issue,
but given the formatting of the text, it didn't seem all that
important.

Thing is, now I realize that the sample text attached to that ticket
was skewing the issue. The bad syntax was just escalating the problem.
The fact is, the current way `_process_section` works (it recursively
calls itself on each block of remaining text), we can easily reach max
recursion with perfectly good syntax.

Therefore, I created a document the following way:

    import sys
    t = ""
    for i in range(sys.getrecursionlimit()):
        t += "Paragraph %d.\n\n" % i

That's 1000 paragraphs one line each - as simple of markdown syntax as
one could have. Even so:

    html = markdown.markdown(t)
    ...
    RuntimeError: maximum recursion depth exceeded

I played with a few different numbers and 985 was the magic number.
The maximum paragraphs a markdown document can have is 984. That's
assuming no lists, blockquotes or anything else that necessarily goes
deeper into recursion.

While replacing recursion with a loop is probably easier said than
done, do we care? In other words, are we ok limiting the possible
length of documents we can process - with that limit becoming shorter
the more complex the syntax used?

If so, I'll just catch the exception and output a friendlier message.

If not, we may have some work to do - although I'd suggest not holding
up 1.7 for it.

[1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1763338&group_id=153041&atid=790198

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

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

Ok, I've worked out some logging code and tested it in all supported
versions of python (2.3 is a pain to configure compared to 2.4 & 2.5).
The question is, do we want to leave the api the same and wrap logging
in our existing `message` method, or use logging directly? It's no
trouble to do either. See the attached test file for examples.

Any suggestions/improvements to the message format?
Currently: NAME-LEVEL: "MESSAGE"

The attached sample outputs the following:

    MARKDOWN-DEBUG: "A debug message"
    MARKDOWN-INFO: "info message"
    MARKDOWN-WARNING: "warn message"
    MARKDOWN-ERROR: "error message"
    MARKDOWN-CRITICAL: "critical message"
    MARKDOWN-WARNING: "a warning"
    MARKDOWN-CRITICAL: "A Message using Markdown's existing api"

I'll also mention that we could define our own levels, but why?


On Nov 16, 2007 12:52 AM, Yuri Takhteyev <qar...@gm...> wrote:
> Oh, well, what do we sociologists know...  Sure, let's send it to stderr.
>
>   - yuri
>
>
>
> On Nov 15, 2007 11:25 PM, Waylan Limberg <wa...@gm... > wrote:
> >
> > On Nov 15, 2007 9:13 PM, Yuri Takhteyev < qar...@gm...> wrote:
> > > Not all messages are errors, so they probably shouldn't all go to the
> error
> > > stream.  Or should they?
> >
> > Yes they should - that's the general convention as I see it. Its a
> > poorly named status stream. In fact, the logging module sends all
> > messages (including non-error) to the error stream by default.
> > Consider this simple commandline example:
> >
> > As it goes currently, when we run this command:
> >
> >    $ python markdown.py input.txt > output.html
> >
> > Any messages will get output to stdout, which in this case is
> > output.html. However, if all messages are sent to stderr, then they
> > would display on the console - not in output.html. I would say that is
> > the desired behavior. I shouldn't have to open the file to see if any
> > messages were generated.
> >
> > In the case of a wsgi app (and by extension most wsgi web frameworks),
> > anything that would get logged is expected to go to stderr. Stdout is
> > expected to be disabled. Seeing stderr & stdout are the only two
> > options we have, stderr is the only acceptable choice here.
> >
> > I could be wrong, but I'd say it's also more likely that if output to
> > the console is not an option, applications of any kind are more likely
> > to redirect stderr than stdout. So if we use stderr, the messages are
> > more likely to go were the developers want them to.
> >
> >
> > >
> > > I think at the time I was thinking in fact of using messages for
> non-error
> > > messages and using print_error() for errors.  Now, arguably
> > > message(CRITICAL, "...") should be interpreted as an error.  Perhaps the
> > > thing to do is to follow Trent's suggestion and to yank this function
> out
> > > altogether and replace with with calls to logging.  Less confusion.
> >
> > I forgot about logging, so thanks Trent. Yeah that certainly makes the
> > most sense. But, just redirecting the current system to stderr would
> > accomplish the same end. Therefore, I'm inclined to just do the
> > quickfix now and work on logging for later.
> >
> > One additional advantage that logging would give us is that is should
> > be easier for others to send the messages wherever they want - stderr,
> > stdout, a log file, a blackhole... Then, when someone finds a
> > new/different environment to use markdown in, it's easy for them to
> > get it to work the way they need/want. It defiantly makes sense to use
> > logging long term.
> >
> >
> >
> >
> > >
> > >   - yuri
> > >
> > >
> > >
> > >
> > > On Nov 15, 2007 5:56 PM, Waylan Limberg <wa...@gm... > wrote:
> > > >
> > > >
> > > >
> > > > I should mention the easy fix. Just have `message` write to
> `sys.stderr`:
> > > >
> > > >      def message(level, text) :
> > > >          if level >= MESSAGE_THRESHOLD :
> > > >     -        print text
> > > >    +        print >> sys.stderr, text          # or
> > > sys.stderr.write(text+'\n')
> > > >
> > > > But, is that good enough or should we use python's built-in
> > > error-handling?
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > >
> > > > On Nov 15, 2007 3:35 PM, Waylan Limberg < wa...@gm... > wrote:
> > > > >
> > > > > Below is the text of the bug [1] I just filed. The reason I'm
> posting
> > > > > here is to get some feedback. Why was it done the way it is? Is
> there
> > > > > any good reason not to change?
> > > > >
> > > > > [1]:
> > >
> http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198
> > > > >
> > > > > > Currently, caught errors are handled by the `message` method which
> > > > > > uses `print` to display error/warning messages. As `print` outputs
> to
> > > > > > `sys.stout` by default, this conflicts with the wsgi spec [1].
> > > > > >
> > > > > > To my knowledge, wsgi_mod [2] is the only server that enforces the
> > > > > > spec here, but in doing so, any `message` generated by markdown
> would
> > > > > > cause a `500` response by wsgi_mod. As most any python
> web-framework
> > > > > > has a wsgi interface, we should expect python-markdown to be used
> in
> > > > > > wsgi environments repeatedly and IMO support such use. FYI, I
> first
> > > > > > came across the problem here [3].
> > > > > >
> > > > > > We could just raise exceptions, but python trackbacks can be ugly
> > > > > > (especially when were dealing with an end user and markdown syntax
> > > > > > errors) and we need multiple levels. Perhaps we should be using
> the
> > > > > > warnings module [3] (available since Python 2.1) which outputs to
> > > > > > `sys.stderr` by default.
> > > > > >
> > > > > > [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> > > > > > [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> > > > > > [3]: http://code.djangoproject.com/ticket/2910#comment:12
> > > > > > [4]: http://docs.python.org/lib/module-warnings.html
> > > > >
> > > > >
> > > > > --
> > > > > ----
> > > > > Waylan Limberg
> > > > > wa...@gm...
> > > > >
> > > >
> > > >
> > > >
> > > > --
> > > > ----
> > > > Waylan Limberg
> > > > wa...@gm...
> > > >
> > > >
> -------------------------------------------------------------------------
> > > > This SF.net email is sponsored by: Microsoft
> > > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > > 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
> > > >
> > >
> > >
> > >
> > > --
> > > Yuri Takhteyev
> > > Ph.D. Candidate, UC Berkeley School of Information
> > > http://takhteyev.org/, http://www.freewisdom.org/
> >
> >
> >
> > --
> > ----
> >
> >
> >
> > Waylan Limberg
> > wa...@gm...
> >
>
>
>
> --
>
>
> Yuri Takhteyev
> Ph.D. Candidate, UC Berkeley School of Information
> http://takhteyev.org/, http://www.freewisdom.org/



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

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

Oh, well, what do we sociologists know...  Sure, let's send it to stderr.

  - yuri

On Nov 15, 2007 11:25 PM, Waylan Limberg <wa...@gm...> wrote:

> On Nov 15, 2007 9:13 PM, Yuri Takhteyev <qar...@gm...> wrote:
> > Not all messages are errors, so they probably shouldn't all go to the
> error
> > stream.  Or should they?
>
> Yes they should - that's the general convention as I see it. Its a
> poorly named status stream. In fact, the logging module sends all
> messages (including non-error) to the error stream by default.
> Consider this simple commandline example:
>
> As it goes currently, when we run this command:
>
>    $ python markdown.py input.txt > output.html
>
> Any messages will get output to stdout, which in this case is
> output.html. However, if all messages are sent to stderr, then they
> would display on the console - not in output.html. I would say that is
> the desired behavior. I shouldn't have to open the file to see if any
> messages were generated.
>
> In the case of a wsgi app (and by extension most wsgi web frameworks),
> anything that would get logged is expected to go to stderr. Stdout is
> expected to be disabled. Seeing stderr & stdout are the only two
> options we have, stderr is the only acceptable choice here.
>
> I could be wrong, but I'd say it's also more likely that if output to
> the console is not an option, applications of any kind are more likely
> to redirect stderr than stdout. So if we use stderr, the messages are
> more likely to go were the developers want them to.
>
> >
> > I think at the time I was thinking in fact of using messages for
> non-error
> > messages and using print_error() for errors.  Now, arguably
> > message(CRITICAL, "...") should be interpreted as an error.  Perhaps the
> > thing to do is to follow Trent's suggestion and to yank this function
> out
> > altogether and replace with with calls to logging.  Less confusion.
>
> I forgot about logging, so thanks Trent. Yeah that certainly makes the
> most sense. But, just redirecting the current system to stderr would
> accomplish the same end. Therefore, I'm inclined to just do the
> quickfix now and work on logging for later.
>
> One additional advantage that logging would give us is that is should
> be easier for others to send the messages wherever they want - stderr,
> stdout, a log file, a blackhole... Then, when someone finds a
> new/different environment to use markdown in, it's easy for them to
> get it to work the way they need/want. It defiantly makes sense to use
> logging long term.
>
> >
> >   - yuri
> >
> >
> >
> >
> > On Nov 15, 2007 5:56 PM, Waylan Limberg <wa...@gm...> wrote:
> > >
> > >
> > >
> > > I should mention the easy fix. Just have `message` write to
> `sys.stderr`:
> > >
> > >      def message(level, text) :
> > >          if level >= MESSAGE_THRESHOLD :
> > >     -        print text
> > >    +        print >> sys.stderr, text          # or
> > sys.stderr.write(text+'\n')
> > >
> > > But, is that good enough or should we use python's built-in
> > error-handling?
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > On Nov 15, 2007 3:35 PM, Waylan Limberg < wa...@gm...> wrote:
> > > >
> > > > Below is the text of the bug [1] I just filed. The reason I'm
> posting
> > > > here is to get some feedback. Why was it done the way it is? Is
> there
> > > > any good reason not to change?
> > > >
> > > > [1]:
> >
> http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198
> > > >
> > > > > Currently, caught errors are handled by the `message` method which
> > > > > uses `print` to display error/warning messages. As `print` outputs
> to
> > > > > `sys.stout` by default, this conflicts with the wsgi spec [1].
> > > > >
> > > > > To my knowledge, wsgi_mod [2] is the only server that enforces the
> > > > > spec here, but in doing so, any `message` generated by markdown
> would
> > > > > cause a `500` response by wsgi_mod. As most any python
> web-framework
> > > > > has a wsgi interface, we should expect python-markdown to be used
> in
> > > > > wsgi environments repeatedly and IMO support such use. FYI, I
> first
> > > > > came across the problem here [3].
> > > > >
> > > > > We could just raise exceptions, but python trackbacks can be ugly
> > > > > (especially when were dealing with an end user and markdown syntax
> > > > > errors) and we need multiple levels. Perhaps we should be using
> the
> > > > > warnings module [3] (available since Python 2.1) which outputs to
> > > > > `sys.stderr` by default.
> > > > >
> > > > > [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> > > > > [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> > > > > [3]: http://code.djangoproject.com/ticket/2910#comment:12
> > > > > [4]: http://docs.python.org/lib/module-warnings.html
> > > >
> > > >
> > > > --
> > > > ----
> > > > Waylan Limberg
> > > > wa...@gm...
> > > >
> > >
> > >
> > >
> > > --
> > > ----
> > > Waylan Limberg
> > > wa...@gm...
> > >
> > >
> -------------------------------------------------------------------------
> > > This SF.net email is sponsored by: Microsoft
> > > Defy all challenges. Microsoft(R) Visual Studio 2005.
> > > 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
> > >
> >
> >
> >
> > --
> > Yuri Takhteyev
> > Ph.D. Candidate, UC Berkeley School of Information
> > http://takhteyev.org/, http://www.freewisdom.org/
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



-- 
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

Not all messages are errors, so they probably shouldn't all go to the error
stream.  Or should they?

I think at the time I was thinking in fact of using messages for non-error
messages and using print_error() for errors.  Now, arguably
message(CRITICAL, "...") should be interpreted as an error.  Perhaps the
thing to do is to follow Trent's suggestion and to yank this function out
altogether and replace with with calls to logging.  Less confusion.

  - yuri


On Nov 15, 2007 5:56 PM, Waylan Limberg <wa...@gm...> wrote:

> I should mention the easy fix. Just have `message` write to `sys.stderr`:
>
>      def message(level, text) :
>          if level >= MESSAGE_THRESHOLD :
>     -        print text
>    +        print >> sys.stderr, text          # or sys.stderr.write
> (text+'\n')
>
> But, is that good enough or should we use python's built-in
> error-handling?
>
> On Nov 15, 2007 3:35 PM, Waylan Limberg <wa...@gm...> wrote:
> >
> > Below is the text of the bug [1] I just filed. The reason I'm posting
> > here is to get some feedback. Why was it done the way it is? Is there
> > any good reason not to change?
> >
> > [1]:
> http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198
> >
> > > Currently, caught errors are handled by the `message` method which
> > > uses `print` to display error/warning messages. As `print` outputs to
> > > `sys.stout` by default, this conflicts with the wsgi spec [1].
> > >
> > > To my knowledge, wsgi_mod [2] is the only server that enforces the
> > > spec here, but in doing so, any `message` generated by markdown would
> > > cause a `500` response by wsgi_mod. As most any python web-framework
> > > has a wsgi interface, we should expect python-markdown to be used in
> > > wsgi environments repeatedly and IMO support such use. FYI, I first
> > > came across the problem here [3].
> > >
> > > We could just raise exceptions, but python trackbacks can be ugly
> > > (especially when were dealing with an end user and markdown syntax
> > > errors) and we need multiple levels. Perhaps we should be using the
> > > warnings module [3] (available since Python 2.1) which outputs to
> > > `sys.stderr` by default.
> > >
> > > [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> > > [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> > > [3]: http://code.djangoproject.com/ticket/2910#comment:12
> > > [4]: http://docs.python.org/lib/module-warnings.html
> >
> >
> > --
> > ----
> > Waylan Limberg
> > wa...@gm...
> >
>
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2005.
> 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
>



-- 
Yuri Takhteyev
Ph.D. Candidate, UC Berkeley School of Information
http://takhteyev.org/, http://www.freewisdom.org/

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

[Trent M. <tr...@gm...>]

> But, is that good enough or should we use python's built-in error-handling?

There is also the logging module.

  log = logging.getLogger("markdown")
  ...
  log.warn("boom!")

Trent

-- 
Trent Mick
tr...@gm...

Re: [Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

I should mention the easy fix. Just have `message` write to `sys.stderr`:

      def message(level, text) :
          if level >= MESSAGE_THRESHOLD :
     -        print text
    +        print >> sys.stderr, text          # or sys.stderr.write(text+'\n')

But, is that good enough or should we use python's built-in error-handling?

On Nov 15, 2007 3:35 PM, Waylan Limberg <wa...@gm...> wrote:
>
> Below is the text of the bug [1] I just filed. The reason I'm posting
> here is to get some feedback. Why was it done the way it is? Is there
> any good reason not to change?
>
> [1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198
>
> > Currently, caught errors are handled by the `message` method which
> > uses `print` to display error/warning messages. As `print` outputs to
> > `sys.stout` by default, this conflicts with the wsgi spec [1].
> >
> > To my knowledge, wsgi_mod [2] is the only server that enforces the
> > spec here, but in doing so, any `message` generated by markdown would
> > cause a `500` response by wsgi_mod. As most any python web-framework
> > has a wsgi interface, we should expect python-markdown to be used in
> > wsgi environments repeatedly and IMO support such use. FYI, I first
> > came across the problem here [3].
> >
> > We could just raise exceptions, but python trackbacks can be ugly
> > (especially when were dealing with an end user and markdown syntax
> > errors) and we need multiple levels. Perhaps we should be using the
> > warnings module [3] (available since Python 2.1) which outputs to
> > `sys.stderr` by default.
> >
> > [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> > [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> > [3]: http://code.djangoproject.com/ticket/2910#comment:12
> > [4]: http://docs.python.org/lib/module-warnings.html
>
>
> --
> ----
> Waylan Limberg
> wa...@gm...
>



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

[Python-markdown-discuss] Errors/Warnings should output to `sys.stderr`

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

Below is the text of the bug [1] I just filed. The reason I'm posting
here is to get some feedback. Why was it done the way it is? Is there
any good reason not to change?

[1]: http://sourceforge.net/tracker/index.php?func=detail&aid=1832747&group_id=153041&atid=790198

> Currently, caught errors are handled by the `message` method which
> uses `print` to display error/warning messages. As `print` outputs to
> `sys.stout` by default, this conflicts with the wsgi spec [1].
>
> To my knowledge, wsgi_mod [2] is the only server that enforces the
> spec here, but in doing so, any `message` generated by markdown would
> cause a `500` response by wsgi_mod. As most any python web-framework
> has a wsgi interface, we should expect python-markdown to be used in
> wsgi environments repeatedly and IMO support such use. FYI, I first
> came across the problem here [3].
>
> We could just raise exceptions, but python trackbacks can be ugly
> (especially when were dealing with an end user and markdown syntax
> errors) and we need multiple levels. Perhaps we should be using the
> warnings module [3] (available since Python 2.1) which outputs to
> `sys.stderr` by default.
>
> [1]: http://www.python.org/dev/peps/pep-0333/#error-handling
> [2]: http://code.google.com/p/modwsgi/wiki/DebuggingTechniques
> [3]: http://code.djangoproject.com/ticket/2910#comment:12
> [4]: http://docs.python.org/lib/module-warnings.html


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

Re: [Python-markdown-discuss] the wiki

[Trent M. <tr...@gm...>]

> You're pretty much right on there. Bazaar is written in Python, if I'm
> not mistaken. Guido uses GIT, IIRC, as he authored it. I've used BZR

You are mixing Guido with Linus. Linus uses GIT. He authored it -- at
least initially.

Guido uses svn (for Python) and Perforce (at his work at Google) and
probably others.


Trent


-- 
Trent Mick
tr...@gm...

Re: [Python-markdown-discuss] the wiki

[Ben W. <da...@gm...>]

On 11/7/07, Waylan Limberg <wa...@gm...> wrote:
> I may not be exactly right here, but my understanding is that
> Mercurial, git and BZR are all 'distributed', while, of course, SVN is
> not.  Mercurial and git, however, have a very different way of working
> (or at least different commands/workflow/api) than SVN/CSV. BZR, while
> more similar to Mercurial and git under the hood, offers commands and
> workflow that SVN users will feel more comfortable with. I see it as a
> nice middle ground. And if you want, you can use BZR in a remote
> server type situation as well. The best of both worlds. I should
> mention, this is all based upon very little time with  Mercurial and
> git which I currently do not even have installed. However, I am
> happily using both bzr and svn and don't really care which way we go.

You're pretty much right on there. Bazaar is written in Python, if I'm
not mistaken. Guido uses GIT, IIRC, as he authored it. I've used BZR
and had little problem figuring it out. It feels like SVN at first but
it is different. With GIT, there are more commands to execute the same
functionality as BZR.

-- 
Ben Wilson
"Words are the only thing which will last forever" Churchill