In LibreOffice 4.0.4.2: /opt/libreoffice4.0/program/python Python 3.3.0 (default, Jun 11 2013, 12:59:38) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> uno.getConstantByName("com.sun.star.style.ParagraphAdjust.CENTER") 3 >>> uno.getConstantByName("com.sun.star.style.ParagraphAdjust.LEFT") 0 But in LibreOffice 4.1.0.1: /opt/libreoffice/4.1/program/python Python 3.3.0 (default, Jun 18 2013, 17:24:23) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> uno.getConstantByName("com.sun.star.style.ParagraphAdjust.CENTER") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/libreoffice4.1/program/uno.py", line 48, in getConstantByName return pyuno.getConstantByName( constant ) uno.RuntimeException: pyuno.getConstantByName: com.sun.star.style.ParagraphAdjust.CENTERis not a constant >>> uno.getConstantByName("com.sun.star.style.ParagraphAdjust.LEFT") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/libreoffice4.1/program/uno.py", line 48, in getConstantByName return pyuno.getConstantByName( constant ) uno.RuntimeException: pyuno.getConstantByName: com.sun.star.style.ParagraphAdjust.LEFTis not a constant I tried a few other style enumerations (like PageStyleLayout and TabAlign) and they fail as well, but I haven't done broader testing to see if it affects more than just the paragraph style enumerations. This is the first 4.1 release I've tried, so I am not sure if it was present prior to the RC. -- David
Michael: I found these constants in idl file, see http://opengrok.libreoffice.org/xref/core/offapi/com/sun/star/style/ParagraphAdjust.idl#28 but perhaps something's lacking for Python. I don't know how idl and Python are/must be linked. Any idea?
I'm fighting a bit to get a locally buildable 4.x dev tree, but in glancing through recent commits, it looks like the affected pyuno code path (in pyuno_module.cxx) includes some 4.1 branch commits for TypeDescriptionManager changes (such as 2356a480fea6cac8cccaae85c9a2b6a312a9048c and bd2c4e8dc42c04eb05adfa32a0d5ce9c72bcfd5d) that perhaps are involved in the behavior change. Although, I'm thinking now that this may just be an intentional break, or at least acceptable, and getConstantByName is just inappropriate for enumerations. This showed up in an older extension script that I've just been habitually rerunning in each new release. However, in more recent code I realized I've been instantiating uno.Enum() instead, which still works properly: /opt/libreoffice4.1/program/python Python 3.3.0 (default, Jun 18 2013, 17:24:23) [GCC 4.1.2 20080704 (Red Hat 4.1.2-54)] on linux Type "help", "copyright", "credits" or "license" for more information. >>> import uno >>> >>> uno.getConstantByName('com.sun.star.style.ParagraphAdjust.CENTER') Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/opt/libreoffice4.1/program/uno.py", line 48, in getConstantByName return pyuno.getConstantByName( constant ) uno.RuntimeException: pyuno.getConstantByName: com.sun.star.style.ParagraphAdjust.CENTERis not a constant >>> >>> uno.Enum('com.sun.star.style.ParagraphAdjust', 'CENTER') <uno.Enum com.sun.star.style.ParagraphAdjust ('CENTER')> It looks like uno.Enum has been around a long time, so maybe getConstantByName was always wrong for enumerations, and just worked by luck. So this could just be a final break with what has been "don't do that" behavior for a while. If so, it's still an incompatibility with pre-4.1 releases, even if the earlier behavior was accidental, so perhaps it could be mentioned in the 4.1 release notes, if only to save someone else with similar legacy scripts some time identifying the issue.
David: about building, maybe this page would help https://wiki.documentfoundation.org/Development/BuildingOnLinux, except if you already know it. Also, don't hesitate to send a post to the dev mailing list: http://nabble.documentfoundation.org/Dev-f1639786.html
Julien: Thanks, it's mostly just dumb local issues. My current tree was still 3.x, and in trying 4.1 I ran into some new dependency issues due to the age of the build box (Ubuntu 8.04). I was spinning up a vps with a more current environment when I noticed the difference in enumeration handling in older and newer scripts.
If this is intentional, I guess we could close this ? and/or add it to the wiki page around 4.0 ? https://wiki.documentfoundation.org/ReleaseNotes/4.0 :-) thoughts appreciated ?
(In reply to comment #2) > It looks like uno.Enum has been around a long time, so maybe > getConstantByName was always wrong for enumerations, and just worked by > luck. So this could just be a final break with what has been "don't do > that" behavior for a while. If so, it's still an incompatibility with > pre-4.1 releases, even if the earlier behavior was accidental, so perhaps it > could be mentioned in the 4.1 release notes, if only to save someone else > with similar legacy scripts some time identifying the issue. I just added <https://wiki.documentfoundation.org/index.php?title=ReleaseNotes/4.1&oldid=73013>: "Due to changes for the new type.rdb format, uno.getConstantByName no longer works for UNOIDL enum members, only for UNOIDL constants. Even though uno.getConstantByName had only been documented to work for constants, existing code might have relied on the fact that it somewhat accidentally also worked for enum members." Given the vague documentation of PyUNO, it is hard to tell whether this is a "true" regression, but lets stick to a strict reading of getConstantByName's documentation and mark this NOTABUG for now. If this causes a problem for too much existing code, we could extend the implementation of getConstantByName to also work again for enum members.
*** Bug 67366 has been marked as a duplicate of this bug. ***