hcoin
commented
7 years ago P.S. in the case _translated or _translate do not find a match, then just pass the values through to the underlying. Or, even better (for me), would simply enable the two way translation on all gets and sets of attributes after the dictionary is passed in.
There is a long standing custom in C programming, that has bled into dbus, that uses integer return values to not represent integers but to mean what python does with (possibly read-only) sets. In C and hence dbus, we often see a collection of single bits raised to published fixed powers of 2 'ored' together then returned as an integer. And the inverse when accepting parameter arguments.
Likewise a search of nearly any C interface, and hence dbus, will define an integer to not mean an integer, but either an offset in to a C 'enumerated type', or, worse, one of a collection of '#define X_Y Z' statements where X is what python would understand as the name of a variable restricted to a member of a tuple, Y the state of X should the integer == Z. In python just a member of the tuple, or possibly set.
To avoid many instances of 'cruft' in the form of decorators and subclassing for that purpose, perhaps pydbus would add a method that would accept a bunch of tuples that contain a regular expression to be matched against _path and a collection of attributes associated with translation instructions, and a method such as _translated(attribute) to and _translate(attribute,value) to set them then call the underlying integer based method.
Or, well, something pythonic. As it is, there will be a great deal of repetitive code being generated by pydbus users to do one-of versions of the foregoing.
I've added a couple entries to the wiki to allow users of 'long term support' distros access to pydbus, as well as a roadmap to get the latest python, and pydbus without needed elevated privileges on any distro with an example for centos 7.