[prev in list] [next in list] [prev in thread] [next in thread] 

List:       pykde
Subject:    Re: [PyQt] Missing error detection in consolidated module
From:       Phil Thompson <phil () riverbankcomputing ! co ! uk>
Date:       2010-03-10 20:32:51
Message-ID: 683a68b708f2868f4dd68c3743555d53 () localhost
[Download RAW message or body]

On Wed, 10 Mar 2010 20:55:10 +0100, Giovanni Bajo <rasky@develer.com>
wrote:
> Hi Phil,
> 
> the module init function generated for PyQt in consolidated mode
> contains this comment:
> 
>     /*
>      * Note that we don't complain if the module can't be imported.  This
>      * is a favour to Linux distro packagers who like to split PyQt into
>      * different sub-packages.
>      */
> 
> Ignoring all PyQt errors is a little unfortunate because it hides also
> installation errors like this:
> 
> ImportError: libglib-2.0.so.0: symbol __abort_msg, version GLIBC_PRIVATE
> not defined in file libc.so.6 with link time reference
> 
> which makes it very hard to debug.
> 
> I don't see a perfect solution here. Ideally, one should ignore only
> errors if the corresponding subpackage does not exist (file not found),
> but I understand it's not easy to detect because they all end up as
> "ImportError".
> 
> What about a compromise where you only let propagate QtCore import
> errors? That module should always exists, so it shouldn't break
> anything, and it would be detecting serious installation issues like the
> one I pasted.

I'll add it to the TODO (but with low priority). It would need some sort of
SIP change because the relevant code is auto-generated.

As far as I am concerned it is a Python bug - it should make a distinction
between failing to import because the module is missing (which is perfectly
legitimate) and because there is an error with the module.

Phil
_______________________________________________
PyQt mailing list    PyQt@riverbankcomputing.com
http://www.riverbankcomputing.com/mailman/listinfo/pyqt
[prev in list] [next in list] [prev in thread] [next in thread]