If the goal is to make the decoding reversible, I agree this is a good strategy. But how commonly is reversibility required? When I read values from DBus, I don't usually write them back. I write different values instead, which will usually come from other sources and start off as normal Python objects. When I ask for an integer, I don't care if it was originally 8, 16 or 32 bits, all I care is that I can use it as a Python int (do arithmetic, etc.). When I write an integer, I want the library to figure out the right representation to use, which it should be able to do since it has access to the schema. Or maybe the goal is to avoid relying on introspection at runtime?

FWIW I think the tuples format is fine for internal representation, but it just feels out of place in a public API.

And BTW it doesn't need to be a dichotomy. I can probably put together a PR to make the tuple format opt-out, by setting a flag on the .new_proxy() call or globally. If that's agreeable.

When I write an integer, I want the library to figure out the right representation to use, which it should be able to do since it has access to the schema. Or maybe the goal is to avoid relying on introspection at runtime?

The inside types of a Variant are not actually a part of schema or introspection. You have to go look for some third party documentation to figure out what types does a specific daemon accepts for specific method.

But how commonly is reversibility required? When I read values from DBus, I don't usually write them back.

This is how NetworkManager connection settings work. (read-update-write) Losing the type information would mean trying to write signed integer in to unsigned field.

We have recently started working on helper classes for those NetworkManager connection settings that have information about dbus types inside so the variant tuples could be avoided. (such classes also can be initialized as a simple Python classes and have type hints)

I would rather add functions that help with working on variants.

The inside types of a Variant are not actually a part of schema or introspection.

Oh interesting, I could've sworn it was. What a missed opportunity. It makes a lot of sense then.

I would rather add functions that help with working on variants.

Yes, I think implementing specialised classes and functions that help encode knowledge about the types in the code rather than the objects will be the way to go. 👍

Here's a method I use:

async def _listen_added(self) -> None:
    async for path, interfaces in self._obj_manager.interfaces_added:
        if BLUEZ_DEVICE_INTERFACE not in interfaces:
            continue
        device_interface = interfaces[BLUEZ_DEVICE_INTERFACE]
        if (
            "ServiceData" not in device_interface
            or HUE_SERVICE_UUID not in device_interface["ServiceData"][1]
        ):
            continue
        device = Device(
            id=path.replace("/org/bluez/", ""),
            alias=device_interface["Alias"][1],
            address=device_interface["Address"][1],
            connected=device_interface["Connected"][1],
            paired=device_interface["Paired"][1],
            rssi=device_interface["RSSI"][1],
        )
        await self._events_queue.put(DeviceEvent(DeviceEventType.ADDED, device))

But I don't think it illustrates my point well. Sure, having the naked values would have allowed me to skip all the [1]s and to simplify the second if to if HUE_SERVICE_UUID not in device_interface.get("ServiceData", ()), but that's minor.

What actually frustrated me was the fact that I had to visually inspect the payload to make sure I was extracting the right values. I had D-Feet open and was expecting to find a string, yet got a tuple instead, and was initially confused. I think some documentation would've made it better, but I'd still have questioned why the payload was like that when D-Feet could list the exact type.

That sounds awesome! But didn't you say introspection didn't have the full variants schema? Is the idea to allow the user to provide a template class?

InterfacesAdded in particular contains a dict with the interfaces and properties (if any) that have been added to the given object path. The idea is that we already have interfaces classes so might reuse them.

This is how I think it should look like once I implement a helper method:

async def _listen_added(self) -> None:
    async for path, cached_interface in self._obj_manager.interface_object_added(DeviceInterface):
        if HUE_SERVICE_UUID not in cached_interface.service_data:
             continue

        device = Device(
            id=path.replace("/org/bluez/", ""),
            alias=cached_interface.alias,
            address=cached_interface.address,
            connected=cached_interface.connected,
            paired=cached_interface.paried,
            rssi=cached_interface.rssi,
        )
        await self._events_queue.put(DeviceEvent(DeviceEventType.ADDED, device))

This looks great. There's probably something similar to be done about the org.freedesktop.DBus.Properties.PropertiesChanged signal.

This looks great. There's probably something similar to be done about the org.freedesktop.DBus.Properties.PropertiesChanged signal.

PropertiesChanged signal only returns the changed properties so building entire class won't be possible. However, it does need a helper method that returns values in python names.

That's awesome, thanks for the update!