On 16/05/2019 14:41, Thomas Viehmann wrote:
To move this forward or abandon:
0. I had half hoped that someone would step in and say that needing to
pass a sequence of Any wrapped in a single Any to an interface is a rare
thing.
1. If we were to form the opinion that not that many extension will be
impacted, would this be changeable or do we prefer to not apply breaking
changes at any rate?
2. If 1. is yes, would investigating github projects featuring "import
uno" and checking whether and how they use "Any" interfaces be an OKish
assessment method?
Lets hope that somebody else with an actual interest in PyUNO steps in
for the above.
One further question is whether you'd want to do the change only for
Python string tuples, or also for further kinds of Python tuples whose
elements are all mappings of some UNOIDL type other than string?
3. Independent of 1 and 2, maybe it would be a good idea to accept
constructed Any values when the UNOIDL signature demands Any to avoid
having to go through uno.invoke. I think having to spell Any("[]String",
...) instead of ... is still much better than going through invoke. Also
it might be nice to annotate known cases of needing to do this for
Python in the API docs.
If with "API docs" you mean the comments in the {off,udk}api/ *.idl
files: I'd prefer to keep those language-binding--agnostic.
_______________________________________________
LibreOffice mailing list
LibreOffice@xxxxxxxxxxxxxxxxxxxxx
https://lists.freedesktop.org/mailman/listinfo/libreoffice