Re: Converting Python Tuples / Lists into Any in PyUNO
Stephan Bergmann wrote: > On 16/05/2019 14:41, Thomas Viehmann wrote: > > 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. > Well mostly a user for that one - that said, perhaps this github research could inform further discussions (e.g. if we find many instances, it's probably a non-starter. if we don't, could tip the balance to do a low-impact cleanup)? Alternatively, we could consider collecting breaking changes in an experimental mode, and at some stage pull a 'python2 -> python3' alike move. Cheers, -- Thorsten signature.asc Description: PGP signature ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Converting Python Tuples / Lists into Any in PyUNO
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@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Converting Python Tuples / Lists into Any in PyUNO
Hello Stephan,
thank you for weighing in!
On 16/05/2019 09:20, Stephan Bergmann wrote:
On 15/05/2019 15:27, Thomas Viehmann wrote:
but that isn't really what this is about, it's about what sequence
types are expected when an any is passed.
My intuition would be that the more specific type is better when
applicable, but I would value your input whether such a change would
be considered an improvement.
There is no "better" or "worse" here, just "right" or "wrong".
In terms of calling the UNO method, I agree. However, I would venture
"better" binding API would be one that offers fewer surprises which is
where I don't see this as great.
That is, the PyUno language binding had to make a choice how to e.g. map
a Python tuple of strings into a UNOIDL any value. It may be debatable
whether the current choice (apparently mapping to a sequence
instead of, say, a sequence) is useful. Be aware that revising
that choice is an incompatible change. It may make writing certain
Python code more intuitive, but at the same time it may break existing
code.
Yeah, well, to me it looks like this was potentially done by accident
because reducing the sequence conversion to item conversion is very
attractive to the one implementing this API but the resulting API is
maybe less attractive to the one using it.
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?
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.
Best regards
Thomas
___
LibreOffice mailing list
LibreOffice@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/libreoffice
Re: Converting Python Tuples / Lists into Any in PyUNO
On 15/05/2019 15:27, Thomas Viehmann wrote: but that isn't really what this is about, it's about what sequence types are expected when an any is passed. My intuition would be that the more specific type is better when applicable, but I would value your input whether such a change would be considered an improvement. There is no "better" or "worse" here, just "right" or "wrong". If some UNOIDL construct documents requirements for a type (e.g., used as an interface method parameter type), then any code using that construct must adhere to those requirements. While it can be easy for a UNO language binding to automatically "fix things up" when e.g. an UNOIDL interface method has a parameter of type sequence and the (Python) caller code passes in a Python object that would normally be mapped to a UNOIDL sequence, there can be no magic fixup when the parameter is of type any and only some additional protocol (unknown to the language binding; e.g., some documentation of the UNOIDL method) dictates the requirement that a certain call of that method must e.g. actually pass in a sequence wrapped in that any. That is, the PyUno language binding had to make a choice how to e.g. map a Python tuple of strings into a UNOIDL any value. It may be debatable whether the current choice (apparently mapping to a sequence instead of, say, a sequence) is useful. Be aware that revising that choice is an incompatible change. It may make writing certain Python code more intuitive, but at the same time it may break existing code. ___ LibreOffice mailing list LibreOffice@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/libreoffice
