search

altdesktop / python-dbus-next

🚌 The next great DBus library for Python with asyncio support
https://python-dbus-next.readthedocs.io/en/latest/
MIT License
187 stars 59 forks source link

signal handlers: check for number of arguments gets fooled by **kwargs handler #90

Open hsteinhaus opened 3 years ago

hsteinhaus commented 3 years ago

I am trying to register one generic handler to a couple of DBus signals with different signatures. This should be not a big deal in the world of duck typing - just use **kwargs in your handler and see what number of args you get.

Unfortunately, dbus-next is stopping me here: https://github.com/altdesktop/python-dbus-next/blob/04e7c0428ec2e4020d4b95aa70e10feb8e53e22e/dbus_next/proxy_object.py#L105

This check comes to the conclusion that my handler has one argument (**kwargs), but my signal has two.

Is there any chance to improve this check, opt out of it or remove it completely? I think this static understanding of the number of arguments is not very Pythonic.

ydirson commented 3 years ago

A keyword argument needs a keyword for naming, where would you expect them to come from ?

hsteinhaus commented 3 years ago

Correct, my mistake. However, *args would probably trigger exactly the same problem.

acrisci commented 3 years ago

I think I can remove that check.

hsteinhaus commented 3 years ago

A keyword argument needs a keyword for naming, where would you expect them to come from

From DBus introspection information?

Currently thinking about implementig that way - would be extremely helpful for my usecase (a single subscriber monitors a bunch of signals). Has anybody tried that before and is there a reason against that I should be aware?