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