Re: Supporting attribute-like properties

If by "penalty-free way" you mean not taking a performance hit, I would just run timing tests for your use cases with all available approaches. As for trying to find a cleaner way to do it, you might consider attempting to use the GObject override mechanism which allows injecting "shim" classes within a GObject class hierarchy (see the pygobject source under the overrides folder for examples). For instance, you might be able to create an override class for WebKit.DOMObject (this seems to be a common base among the classes used in your script) and implement __getattr__ and __setattr__. Not sure if it will work but it may be worth a try.


On Sat, May 26, 2012 at 12:31 AM, C Anthony Risinger <anthony xtfx me> wrote:
On Sat, May 26, 2012 at 1:50 AM, Simon Feltman <s feltman gmail com> wrote:
> Hi Kerrick,
> Properties on classes and objects pulled in through introspection have a
> "props" accessor. So with your example but using myLabel.props.angle should
> already work.
> If the GObject property was created in python, then the property will be
> directly accessible on the object as well (GObject.Property supports the
> descriptor and decoration protocols similar pythons built-in "property")
> from gi.repository import GObject
> class Label(GObject.GObject):
>     angle = GObject.Property(type=float)
> myLabel = Label()
> myLabel.angle = myLabel.angle + 180

interesting ... i am working on a bindings to pygi+webkit for an
existing project that already runs on several other engines
(Trident/XULRunner/PythonWebKit), and one of the problems is our DOM
code (among others) expects attributes to be available per the W3C
specs, eg. window.getLocation(), document.createElement() and the like
... ie. camelCase.

my current approach is to hijack __getattr__ and __setattr__ for key
classes related to DOM/etc, and, in the simple case, inject camelCase
"aliases" to gobject_attributes as needed, this seems to work pretty
good as camelCase is all-but-guaranteed to fail *one time*; once set
there is no performance penalty.

however, attributes on `.props` require a different approach ... so i
am instead dynamically generating a descriptor that does little more
than call `instance.get_property(some_property)`.  so far i've seen no
ill-effects but it's not well tested ... is there a penalty-free way
to do this as well?

the code is *very* experimental and nasty looking, but it's all done
in this one function:

... not trying to derail the thread here, but i have the same "issue"
so-to-speak; is there a better/cleaner way to do all of this?  i need
to expose gobject_based_attrs and methods in a more "_javascript_-y",
W3C kind of way ... what would you suggest?  and is there any
considerations i should be aware of in my current approach?


C Anthony

[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]