Wouldn't the combination of -r and -w already work as -rw with no additional effort? Or does argparse not provide that?

oh, you are right. I didn't give argparse enough credit, it can do it.
Will fix it in the next rev.

This currently returns the exact same result if the device at addr can read and if it can write, right? I think this interface is not good enough to be in our public API.

This currently returns the exact same result if the device at addr can read and if it can
write, right?

correct.

I think this interface is not good enough to be in our public API.

I actually thought a bit about the interface and this is the one I liked best.

I thought how would one use the scan function. I think the most common use case will
be getting all addresses that answer somehow (read or write) and then iterate over
the result, maybe probing the devices in more detail.

The case were it is relevant to distinguish between read ack and write ack is a valid
use case, but I think it will be used less often. So the interface is easy to use
for the common case and if you want read vs. write, you just call it twice to get separate
lists.

Another idea would be to add methods like scan_read_addr(self, i2c_addr) and scan_write_addr(self, i2c_addr)
which you could use to probe an address in more details when iterating the result list.

The runtime is dominated by the i2c transaction. The scan function in read/write mode
will skip scanning the write addr if it found a read addr, saving time.

Another interface would be to return something like

{
  "0x40" : {
    "read": True,
    "write" : False
  },
  "0x41" : {
    "read": True,
    "write" : True
  }
}

but I'm not sure it is worth to add that complexity for the not-so-common case.

OK.

The scan function in read/write mode will skip scanning the write addr if it found a read addr, saving time.

I actually feel like it's interesting to discover both read and write addresses (as printed in the log), in case some peripheral answers to reads but not writes. What about making found a set() and changing this?

Another useful improvement I think would be to restrict scanning to a few addresses. E.g. I know some peripheral can only be at 0b1000000..0b1000111.

what kind of structure do you want to return exactly? The one I posted above under "Another interface would be" or something else?

A simple set will not convey if a device answered read or write.

I think the current interface (one function) is sufficient.

Another useful improvement I think would be to restrict scanning to a few addresses. E.g. I know some peripheral can only be at 0b1000000..0b1000111.

how about
scan(self, *, read_addrs=True, write_addrs=True, scan_from=0b0001_000, scan_to=0b1111_000)

I'd do something like scan(self, range=range(0b0001_000, 0b1111_000), *, read=True, write=True), personally

ok, but I'd use scan(self, address_sequence=range(0b0001_000, 0b1111_000),... then, because the parameter is a sequence that is just filled with a range by default.

Just addresses is fine then. "Sequence" means a different thing in Python (what you'd call an array in C, strangely enough), and this is an "iterable".

You should mark any boolean flags as keyword-only arguments, like async def scan(self, *, read_addrs=True, write_addrs=True):. (I should add a CONTRIBUTING.md file that explains these things...)

You are right, I wasn't thinking pythonic enough. Will fix that in the next rev.