2005/11/29, Joerg Budischewski <[EMAIL PROTECTED]>:
This seems to work OK. Now the __members__ is working.
But, in fact this is more/less useless, I think (more, __members__ and so are deprecated methods since Python 2.2).
IMHO, the way the "pyuno" is exported to python (basically, just by reimplementing the __getattr__ & __setattr__ methods) is a hack.
It has the (big) advantage that there is only one C object for every UNO service and class, but it is almost impossible to export UNO objects the Python way with this hack.
I mean, the usual way of exporting methods and properties is to define the PyTypeObject's tp_methods, tp_members and tp_getset (and more) struct items.
This cannot be done with one kind of "C metaclass" like it is done now.
The only way (AFAIK) would be to have a tool that create C files from IDL files for every UNO service & interface, accroding the several namespaces (wich would be Python modules then).
It seems that Boost is actually included in OOo, thus it could be used to create Boost.Python wrappers for every C++ class & struct that need to be exported in Python. This should not be very hard.
The main drawback is the pyuno dll would the be notably bigger...But the whole pyuno would then be much more pythonic and maybe notably quicker (not sure of that, btw).
The other way of doing so it, as I suggested, to add the standard class methods & properties in pure Python.
I have succeeded (at least) in making pythonscript.py able to create/edit/rename/delete python scripts.
The editor is still the very poor OOo TextEditor. It can use a Tkinter.Text with syntax colorization, but this worls only if the tcl/tk & tkinter stuff is correctly built, which is not the case with the OOo official binary (under Linux at least).
On my laptop, I have the Suse version of OOo 2.0 in which everything related with Tkinter works fine out of the box (since the python bundled with OOo is the main distrib's python 2.4).
Should I send my file on this list?
Thanks,Hi,
>> thinking to a quite elegant solution using metaclasses).
>> it should be done at the C level, and I think, it shouldn't be too
>> difficult once one knows, which properties to support to achieve this.
> OK, I'll have a look at this ASAP, if you wis ;-)
sure, go ahead.
> I have
> > solved my issues with pythonscript.py .
> I already have a fix for this issue, just wanted to let you know ...
> Is it available on the CVS repository or somewhere else (I have not
> checked yet) ?
well, yes there is an cws cws_src680_pyunofixes2, which is currently
based on a quite SRC680_m106, where several fixes for pyuno went into.
The relevant patch is the last difference in
http://udk.openoffice.org/source/browse/udk/pyuno/source/module/pyuno.cxx?r1=1.6&r2=1.6.12.1
, basically a get() must be replaced by a getAcquired() because of this
strange semantics, that PyList_SetItem steals a reference.
This seems to work OK. Now the __members__ is working.
IMHO, the way the "pyuno" is exported to python (basically, just by reimplementing the __getattr__ & __setattr__ methods) is a hack.
It has the (big) advantage that there is only one C object for every UNO service and class, but it is almost impossible to export UNO objects the Python way with this hack.
I mean, the usual way of exporting methods and properties is to define the PyTypeObject's tp_methods, tp_members and tp_getset (and more) struct items.
This cannot be done with one kind of "C metaclass" like it is done now.
The only way (AFAIK) would be to have a tool that create C files from IDL files for every UNO service & interface, accroding the several namespaces (wich would be Python modules then).
It seems that Boost is actually included in OOo, thus it could be used to create Boost.Python wrappers for every C++ class & struct that need to be exported in Python. This should not be very hard.
The main drawback is the pyuno dll would the be notably bigger...But the whole pyuno would then be much more pythonic and maybe notably quicker (not sure of that, btw).
The other way of doing so it, as I suggested, to add the standard class methods & properties in pure Python.
> One remark. I am not sure the use of "smart-pyref" is really a helpful
> tool. I think this brings more confusion than help in the code. I have
> no time to develop this now, but I can do it later if you think I am wrong.
I agree that this is not the common way how python C code is developed.
However in a world with c++ exceptions it becomes really very tedious to
do the refcounting by hand because want would have to introduce a lot
of additional try{} catch{} clauses to do the recounting right.
You need to concentrate on doing the smart-pyref right, when it is
constructed, but when you achieve this, it is very easy to add more
exits to a function without going through all the refcounting again.
Bye,
Joerg
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
I have succeeded (at least) in making pythonscript.py able to create/edit/rename/delete python scripts.
The editor is still the very poor OOo TextEditor. It can use a Tkinter.Text with syntax colorization, but this worls only if the tcl/tk & tkinter stuff is correctly built, which is not the case with the OOo official binary (under Linux at least).
On my laptop, I have the Suse version of OOo 2.0 in which everything related with Tkinter works fine out of the box (since the python bundled with OOo is the main distrib's python 2.4).
Should I send my file on this list?
David
