[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]
Re: [xml] Python bindings default error handling
- From: Daniel Veillard <veillard redhat com>
- To: "Martin (gzlist)" <gzlist googlemail com>
- Cc: xml gnome org
- Subject: Re: [xml] Python bindings default error handling
- Date: Wed, 7 May 2008 09:17:58 -0400
On Wed, Apr 30, 2008 at 05:13:11PM +0100, Martin (gzlist) wrote:
> Currently libxml2 ignores the value of sys.stderr and prints straight
> to c stderr. This caught me out a couple of times in the past, when
> using from within apache (ended up raw in the error log) and when
> trying to pass on the problems reported to another process. Setting
> your own callback can get the desired effect, but it would be nice for
> this to just work.
>
> Anyway, while I was looking at something more complicated on the error
> handling front (fixing it so the exceptions actually included the
> info), I thought I'd try and patch this in passing.
Hum, there is a more fundamental problem with trying to redirrect
all libxml2 errors to python, simply that your python module may not be
the only part of the application using libxml2, and in a framework like
Apache, this means you're very likely to introduce side effects for
other parts by doing so.
> Went hunting for how other cpython deals with error logging, found a
> couple of things along the right lines.
> In ctypes PrintError <
> http://svn.python.org/view/python/trunk/Modules/_ctypes/callbacks.c?view=markup>
> (attached, extract_ctypes_callback.c) is a minimal version.
> In python itself, PySys_WriteStderr
> <http://svn.python.org/view/python/trunk/Python/sysmodule.c?view=markup>
> (attached, extract_python_sysmodule.c) is pretty much perfect for a
> default error callback, but for the arg mismatch (no dummy void*). The
> mywrite function that actually does all the work covers all bases,
> including short circuiting the common case.
>
> So, one approach is to adapt (err... "copy wholesale") that function
> (attached, libxml2_stderr.patch) for use with the current callback
> function. Do the libxslt bindings also need looking at? I don't
> suggest taking the patch exactly as-is (borrowed function should
> probably go somewhere else at least), but something along these lines
> would be nice.
I'm afraid any approach based on a global automatic redirection is
annoying in highly modulars apps like Apache.
Still the patch makes sense because it doesn't directly increase
the reliance in the global handler.
For libxslt, yes I see a few use cases of stderr in libxslt/python/libxslt.c
and it would be good to clean this up,
Daniel
--
Red Hat Virtualization group http://redhat.com/virtualization/
Daniel Veillard | virtualization library http://libvirt.org/
veillard redhat com | libxml GNOME XML XSLT toolkit http://xmlsoft.org/
http://veillard.com/ | Rpmfind RPM search engine http://rpmfind.net/
[Date Prev][Date Next] [Thread Prev][Thread Next]
[Thread Index]
[Date Index]
[Author Index]