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

[Michael Meeks]

On Wed, 2011-12-07 at 23:44 +0100, Lionel Elie Mamane wrote:
> > 	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.
> 
> We seem to have a deep, deep chasm, because things that are natural /
> intuitive to me seem to be completely misunderstood by you. 

	:-) I'm not sure it's -that- deep - -clearly- from the docs this object
is trying to be a simple name/value property-bag grab-bag. That is clear
enough; the problem is - -what- is in the grab-bag; or (more to the
point) why are there a badzillion built-in things, and not the things I
want ? how does this 'module' map relate to the .py files which are it's
children ?

> The core thing to understand is that a function is not in any way a
> "special" category. It is just a value that can be applied, that can

	Sure - I'm blown away by the sheer meta-ness of it ;-) everything is an
everything and so on :-) But concretely, I don't care - I just want to
understand this:

	* for a given structure of a python module:
		fax/
			__init__.py
			FooBaaBaz.py
			BingBongDing.py

	* what can I expect my 'module' meta-thing to look like ?
		+ ie. given that it contains nothing of any usefulness
		  that I can find; how can I extract the global instance
		  g_magicNameFoo defined in FooBaaBaz.py ?
		+ why can I still not get it if I load
		  fax.FooBaaBaz ?
		+ why does it still not work for fax if I define this
		  magic in __init__.py ?
		+ how does that module structure flatten into this
		  hash ?

> So, it is quite natural (in the Python approach) that a module is just
> a wrapper around a dictionary.

	That is fine - the question is - how is (what looks like a non-flat
hierarchical object) flattened into a flat dictionary ? and where is
that documented ?

> You want to know whether module m defines name FOO?
> "hasattr(m, 'FOO')" will tell you. Either True or False.

	Sure - so much is obvious; that is clearly what it -should- do; but
what does "module m defines name FOO" mean ? where does FOO have to be
defined ? clearly it works if I load/compile etc. the foo.py file - then
the namespacing works and I get what I expect. Without that - how can I
get g_MagicInstanceVariable into the global module scope ?

> But I get the impression that you know that, so that I'm not sure what
> is your issue or question. Let's continue...

	Yes :-) my question is - where is the documentation for any of the "how
a set of files in a module interact and how are there symbols exposed,
-and- how are they flattened into this hash -and- if I cannot find the
symbol at the top-level, how can I traverse this tree - when I get only
a dictionary with nothing I can see that is useful for going down a
level inside it ;-)

> If for some reason you don't want to be liberal and use duck typing,
> and want to force implHelper to be created by
> unohelper.ImplementationHelper() (or a derived class), you can use a
> subytping model:

	Of course, that would be a good check to have I guess ;-) but I'm not
so interested in that, I just want something that works.

> > 	Sure -none of these are what I want; I want to hook out any
> > g_ImplementationHelper instances that are around.
> 
> What is "hook out"? Whatever that is, just get the
> g_ImplementationHelper attribute and do whatever you want with it.

	Sure - except it doesn't work ;-)

> > 	Having some nice way to dump all the available methods, and/or classes
> > on a module
> 
> m.__dict__.keys() gives the set of bound names as a list.

	Sure - and I get a huge list of (mostly) built-ins, with chatty
contents; if there is some way to traverse down to the component .py
files / classes that are embedded in this module, it is really unclear
to me.

> Maybe instead of discussing things in generality, we should dive into
> the concrete problem you are having? Give me UNO/LibreOffice
> n00b/beginner-proof instructions on how to reproduce the problem.

	Sure :-) So - drop this services.rdb over your existing
programservices/services.rdb; unfortunately (it is all one line) .rdb
files are not patch-able. The substantive change is:

  <component loader="com.sun.star.loader.Python"
	     uri="vnd.openoffice.pymodule:wizards.fax">
    <implementation name="com.sun.star.wizards.fax.CallWizard">
      <service name="com.sun.star.wizards.fax.CallWizard"/>
    </implementation>
  </component>

	Re-start, and File->Wizards->Fax should produce this on the console:

pythonloader.Loader ctor
pythonloader.Loader.activate
pythonloader: interpreting url vnd.openoffice.pymodule:wizards.fax
pythonloader: after expansion vnd.openoffice.pymodule:wizards.fax
Warning: Python module loading is almost certainly pre-broken
dump stuff
Fetched ImplHelper as None

	I would expect ImplHelper to not be Null, or have some way of getting
that instance out of the module. I tried all manner of ways of forcing
the modules to get imported inside the __init__.py none of which helped
here.

	Help much appreciated :-)

	ATB,

		Michael.

-- 
michael.meeks at suse.com  <><, Pseudo Engineer, itinerant idiot
-------------- next part --------------
A non-text attachment was scrubbed...
Name: services.rdb.gz
Type: application/x-gzip
Size: 15899 bytes
Desc: not available
URL: <http://lists.freedesktop.org/archives/libreoffice/attachments/20111208/a31e5373/attachment-0001.bin>