[Libreoffice] candidate for a new python section in SDK examples page

Michael Meeks michael.meeks at suse.com
Wed Dec 7 12:04:14 PST 2011

Hi Miklos & Lionel,

On Wed, 2011-12-07 at 17:07 +0100, Miklos Vajna wrote:
> On Wed, Dec 07, 2011 at 03:49:10PM +0000, Michael Meeks <michael.meeks at suse.com> wrote:
> > 	mod = __import__ ( "actual python-module-name" )
> >       implHelper = mod.__dict__.get( "g_ImplementationHelper" , None )
> > 
> > 	is supposed to work, or indeed any half-way decent documentation on
> > what the object is that __import__ returns and by what I don't mean
> > floral vagueness but a concrete set of methods/properties and their
> > types that would let us find an internal variable definition ;-)

	So - I know what __import__ is meant to do - but it appears to return
an entirely useless object; one that has nothing even slightly helpful
associated with it that would let me find an associated member variable.
> Second line:
> implHelper = mod.__dict__.get( "g_ImplementationHelper" , None )
> In short, it checks if there is a funcion named "g_ImplementationHelper"
> in "actual python-module-name".

	Riiight ;-) 'function' or 'object' or ... it is all so un-typed and
meta, it could do almost anything; except it totally fails :-) and even
using interactive python at some length and poking in __dict__ makes me
none the wiser ;-)

> (No, I'm not sure what else that dictionary contains, you can probably
> fool that simple check by providing a *class* named
> g_ImplementationHelper in the module, etc.)

	Sure - except; that it should be a global variable to work right ;-)
anyhow - so Lionel did some python code reading [ it seems that's a
great way to get to some real types ;-]:

On Wed, 2011-12-07 at 18:05 +0100, Lionel Elie Mamane wrote:
> I'm not sure I qualify as "genius", but let me try.

	You'll do for me ;-) I'm impressed.

> http://docs.python.org/reference/datamodel.html and Python's source
> code (Objects/moduleobject.c):

	Ah - so, that does indeed contain a handful of lines that try to
explain the Module 'object' - but these are particularly unhelpful IMHO.
I just constantly hit this feeling that "everything is groovily
un-typed" vibe has bitten the documentation authors, so they feel it
should be obvious what methods, classes, etc. a 'Module' object has
(and/or what is hidden in it's meta internal-grab-bag of stuff); however
it is highly non-obvious to me ;-)

> It is an object of type/class "module". Type module has exactly one
> member:
> __dict__ (read-only): the module's namespace as a dictionary
>   (http://docs.python.org/library/stdtypes.html#typesmapping)
>   __dict__ is the dictionary of attributes of the object. That is, if
>   there is no member BAR in object FOO, then FOO.BAR is
>   FOO.__dict__["BAR"]
> __dict__ is prepopulated by the module loading system with:

	Sure -none of these are what I want; I want to hook out any
g_ImplementationHelper instances that are around.

> > let us find an internal variable definition ;-)
> The code you quoted looks right. I would then continue with:
>  if inspect.isroutine(implHelper):

	The code reliably returned Null to me ;-) for wizards.fax, and for

> to test whether implHelper is a function (something that takes
> arguments and returns a result) as I guess it is expected to be. The
> inspect module having been loaded, obviously.

	Having some nice way to dump all the available methods, and/or classes
on a module - that is clearly annotated, and documented, associated by
the intrinsic type of the object is really helpful. Since I could find
no information about the 'type' of this object, and no way to link that
to the 'inspect' code that (might) provide some of that data - which is
generally quite disappointing.

	Anyhow - perhaps next time I have an hour to dig at the
pyuno/source/loader/pythonloader.py to get module loading (without an
explicit .py filename being passed) working; I guess I can remove the
"this is all busted" type debug print in there ;-)


michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot

More information about the LibreOffice mailing list