Documentation is incorrect on how Enumerator filters are combined

[sm-Fifteen]

The documentation states the following:

Before iteration the device list can be filtered by subsystem or by property values using match_subsystem() and match_property(). Multiple subsystem (property) filters are combined using a logical OR, filters of different types are combined using a logical AND. The following filter for instance:

devices.match_subsystem('block').match_property('ID_TYPE', 'disk').match_property('DEVTYPE', 'disk')

means the following:

subsystem == 'block' and (ID_TYPE == 'disk' or DEVTYPE == 'disk')

This is technically true, and also applies to list_devices, however the way those filters are combined depends on the keys being matched. It was clarified in systemd/systemd#2995 and systemd/systemd#11520 that:

• Matching multiple subsystems combines with OR
• Matching multiple names only matches the last one specified
• Matching multiple properties combines with OR
• Matching multiple attributes combines with AND
• Matching multiple tags combines with AND
• Matching multiple parents only matches the last one specified

---

So if I have a Logitech keyboard (046d:c52b) and mouse (046d:c537) plugged:

>>> import pyudev
>>> context = pyudev.Context()
>>> for device in context.list_devices(subsystem="usb", ID_VENDOR_ID="046d", ID_PRODUCT_ID="c52b"):
...     print(device)
... 
Device('/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.1')
Device('/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.4/1-1.1.4.2')

...property-matching picks up both of them, even if I'm only trying to match the keyboard. However, if I instead attempt attribute-matching:

>>> for device in context.list_devices(subsystem="usb").match_attribute("idVendor", "046d").match_attribute("idProduct", "c52b"):
...     print(device)
... 
Device('/sys/devices/pci0000:00/0000:00:1a.0/usb1/1-1/1-1.1/1-1.1.1')

...only the keyboard is matched, since both filters are combined with AND.

[mulkieran]

@sm-Fifteen Please feel free to go ahead and assemble a PR to fix this problem, I expect I would be able to review it in a few days.. I suspect that the code base no longer includes any tests to verify that these properties of the search hold (because it turns out that the properties and attributes are too volatile, and so the tests will intermittently fail).