Created attachment 18931 [details] [review] fix-rel-path.patch In line 290 in decorators.py it says: if rel_path_keyword is not None: rel_path = keywords.pop(rel_path_keyword, None) func(self, *args, **keywords) Now lets assume we have the following: @dbus.service.signal(IFACE, rel_path_keyword='path', signature='s') def f(x, path) I can now call f('a', path='/example'), but it won't work, because dbus will call f(x) (without path=..) If i define: @dbus.service.signal(IFACE, rel_path_keyword='path', signature='s') def f(x) I can't call f with path=.. So at the moment it is not usable at all, or do i miss something? My suggestion would be to move the function call some lines up
The current behaviour appears to be correct for the intended usage, which is that arguments that are given special treatment by dbus-python are not passed on to user code (although that's poorly documented). class SeriesOfTubes(...) """A series of tubes, which exists with several object paths simultaneously. Each object path represents one tube, but for memory-efficiency, they are all represented by one Python object. """ SUPPORTS_MULTIPLE_OBJECT_PATHS = 1 ... @signal(dbus_interface='com.example.Tube', signature='b', path_keyword='path') def BlockageChanged(self, blocked): logger.debug('blockage changed: %d') series = SeriesOfTubes(...) series.BlockageChanged(True, path='/tube/Hammersmith_and_City') series.BlockageChanged(False, path='/tube/Northern') I'd welcome a patch to document this behaviour more explicitly, or to provide a @signal(..., keep_special_kwargs=True) option that switches to the behaviour you expected.
Sorry, the path_keyword in that example needs replacing with rel_path_keyword. The rest remains true.
-- GitLab Migration Automatic Message -- This bug has been migrated to freedesktop.org's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.freedesktop.org/dbus/dbus-python/issues/16.
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.