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<string> and the (Python) caller code passes in a Python object that would normally be mapped to a UNOIDL sequence<any>, 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<string> 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<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.