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<any> 
> instead of, say, a sequence<string>) 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