https://bugs.freedesktop.org/show_bug.cgi?id=66025
--- Comment #32 from David Bolen <[email protected]> --- Created attachment 82883 --> https://bugs.freedesktop.org/attachment.cgi?id=82883&action=edit Import handler patch Ok, so in looking a little deeper just using the python exception has its own problems. In that case, with Python 3, the python exception for uno failures will just declare an import error of the top level namespace (e.g, "com") since uno.py never actually installs anything in sys.modules. But changing that would break the same semantics I ran into problems with in comment 17 trying the new Python 3 import handler model. So I've opted to try to combine some aspects of both. I re-raise a new exception (so I can include the full name to cover uno issues), but I model the exception text after a regular module import error, and include the original python traceback to better satisfy cases where the issue is outside of LO. I've attached a suggested patch (uno.py.patch), a small test script (exctest.py) and some test output (exctest.txt) reflecting running the script under plain python 2.7.5 and 3.3.2 (no uno), and LibreOffice 3.6.6.2, 4.0.4.2 and 4.1.0.3, both unpatched and patched. I'm attaching them to this ticket since it seems reasonable to treat them as a response to the issue reported here (which I still believe was likely due to a non-LO module error, but obscured by the uno traceback). As the output shows, it's really the LO 4.x and Python 3.x where the unpatched traceback is particularly rough in a python import failure case. LO 3.x isn't all that bad, so while the patch is compatible, I'm not sure it needs back-porting. -- You are receiving this mail because: You are the assignee for the bug.
_______________________________________________ Libreoffice-bugs mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/libreoffice-bugs
