In docs: signal handlers MUST specify signature

[msftcangoblowm]

In Client Interface, signal handlers must specify the signature. This can be confirmed in proxy_object.BaseProxyInterface:_addSignal decorator.

def on_signal_fn(fn):
        fn_signature = inspect.signature(fn)
        if not callable(fn) or len(fn_signature.parameters) != len(intr_signal.args):
            raise TypeError(

So if the signal handlers doesn't contain a matching signature then a TypeError is supposed to be thrown. My experience: never saw a TypeError get thrown!

Therefore, without looking at the source code, there is no way to know why normal signals aren't being triggered.

For example,

def on_signal_simple(str_hello):
    print(f"{str_hello} world")

Will never be triggered.

def on_signal_simple(str_hello: 's'):
    print(f"{str_hello} world")

Will get triggered.

on_property_changed actually does get triggered! Even without the signature. Which only indicates that org.freedesktop.DBus.Properties.PropertyChanged signal handling is handled separately.

Please update the misleading Client Interface documentation, so signal handling is intuitive.

[acrisci]

This method is not intended to require annotations because the type information is in the introspection XML. Would you please investigate the root cause of the issue? A failing test would be nice. Fixing it would be better. Thanks.

[msftcangoblowm]

ISSUE 1

Compared:

• a signal handler function with signature
• a signal handler function without signature

Both pass condition len(fn_signature.parameters) != len(intr_signal.args). So i was mistaken.

ISSUE 2 (new issue)

if signal handler annotation is provided, isn't checked with the annotation of the args.

In python

• function (Python module type) annotation are not checked
• Python programming language is not strictly typed like in C/C++

In DBus

• has Types
• intended to be strictly typed
• a dev could mistake the Type annotation. Receive an unexpected Type, and get no feedback the type (annotations) don't match. For example, receive a 'b' when expecting a 'a(su)'
• Security wise, not checking types from a separate process or user input is a huge coding practice no-no. With dbus methods, rather than dbus signals, then i can imagine DBus System bus service crashing when receiving an arg with an unexpected type. Also possible with signals/properties. The threat however is lower. None the less, it could be fixed.

Do you want to compare annotations if annotations are provided?

In which case, i'm willing to create the fix

[acrisci]

The library always does this. Types are checked against the introspection XML in the high level client (second time saying htis). In the low level client, the signature of the message is always guaranteed to match the body. If this is ever not the case, you may report the bug.