PyUNO usability improvements

[Matthew J. Francis]

Hi,

On 15/06/2015 16:33, Riccardo Magliocchetti wrote:
> Have you tried this against unoconv?
> https://github.com/dagwieers/unoconv

I have now, although you have to do a bit of a funny dance to get it to work 
correctly against a random LO instance.
Specifically, against a current build I had to:
     UNO_PATH=$PWD/instdir PYTHONPATH=$PWD/instdir/program unoconv <args>

It seems to work correctly, and in general I would expect this to be the case. 
You *could* deliberately write code that was forward-incompatible with the new 
syntax options, but you'd have to try something quite silly to do so.

For instance, deliberately relying on the fact that UNO collection objects 
throw exceptions when you try to access them Python style would be incompatible.

> Speaking of pythonic api there was this nice talk which i think fits quite well:
> https://www.youtube.com/watch?v=wf-BqAjZb8M
>
> TLDR; what about adding a pythonic wrapper on top of the actual API to make it
> pythonic?

Thanks for the link, that was an interesting talk - and suggested one more 
feature that could be implemented cheaply, which is to implement a context 
manager for XModel to manage controller locking.

So instead of

     doc.lockControllers()
     try:
         ... # operate on the document
     finally:
         doc.unlockControllers()

You could simply

     with doc:
         ... # operate on the document

(Can anyone suggest any more interfaces which could benefit from this treatment?)


As for the other elements suggested in the talk, UNO properties are already 
mapped to Python properties, which is one of the areas where the existing code 
is quite successful in providing a Pythonic interface; and providing proper 
list, iterator and dict accessors is of course the main thrust of the patch.
The UNO API is huge, and whereas trying to implement a perfect Python 
interface for each UNO object and interface individually would be an enormous 
amount of work, doing this kind of global transform on the whole API should be 
highly effective in achieving (very nearly) the same result.

Regards
Matthew Francis