https://bugs.freedesktop.org/show_bug.cgi?id=66025
--- Comment #17 from David Bolen <[email protected]> --- Tim: Ok, so at first glance I'm guessing that somewhere in your code base there's something like "from pygments.lexers.web import HtmlLexer" which is either (a) new, (b) used to handle the case of a missing pygments module but isn't under LO4+ or (c) the port to Py3 introduced a bug in handling the missing module case that interacts badly with existing LO behavior. While LO (after an uno import) clearly affects the exact exception instance raised, in testing each of 3.6.6, 4.0.4 and 4.1.0, I don't really see any material difference in LO's behavior in this regard. In each case the final exception remains an ImportError. That is, code such as: try: from foo import bar except ImportError: pass seems to work fine in plain Python, and each LO release with or without uno imported. It is true that the text message in the exception differs from a regular Python ImportError, and also that with the shift to Py3 the exception has a "msg" attribute rather than "message". But I wouldn't normally expect any parent code trying to trap an optional module import to depend on that (or if it did, it would be fragile itself across Python versions). Can you perhaps locate the code attempting the import to see how it might be trying to trap the import failure (either itself or through a parent handler up the call chain)? I've downloaded the OpenLP source for 2.0.1, the latest 2.2.2 and a python3-productive branch I found on launchpad, and can't seem to find any reference to pygments anywhere in the source tree? Others: It does feel wrong that simply importing uno changes future import errors (even if just subtly) from statements of the form of "from xxx import yyy". I did do some experiments switch to an import loader instead, but realized that the semantics differ enough as to potentially be an compatibility issue. That is, the current implementation has characteristics of (a) working without needing intermediate "com", "com.sun", and "com.sun.star" modules and (b) working even if some other modules of those names are already imported. The second case is particularly hard to do with a loader. So sticking with the global import hook replacement seems safer. However, I think my earlier patch at the end of comment 14 (which Tim is using) to at least constrain the namespace under which the uno-specific code runs seems like a plausible change, unless anyone is aware of anything accessed via uno not being under the "com.sun.star" namespace. -- 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
