Python: Remove numpy requirement, use buffer protocol instead

[EchterAgo]

Partly taken from #283 (comment)

This removes the requirement of read_barcode / write_barcode to have Numpy installed and uses buffer protocol instead.

Numpy arrays can already be converted to a buffer, for PIL images we get the __array_interface__ and use its values to create a memory view with the right shape.

The write_barcode function now returns a buffer instead of a Numpy array. This buffer also supports __array_interface__ for easy conversion to PIL images or Numpy arrays.

• For PIL: img = Image.fromarray(result, "L")
• For Numpy: img = np.array(result)

fixes #283

Co-authored-by: axxel

TODO:

• Rebase
• Add @axxel as co-author to the commit
• Use Reduce from ZXAlgorithms.h
• Remove the TODO in write_barcode, returning a buffer is OK here
• Clean up code
• Investigate whether we can return WriteResult or py::buffer directly from write_barcode
• Review for memory safety
• Do we need to adjust any documentation?

[EchterAgo]

I fixed the tests, TestReadWrite now runs without numpy, I added additional tests that test buffer protocol and when numpy is installed we also test numpy array conversion. One issue I see right now is that the zxingcpp.write_barcode return type changed from numpy array to a buffer. We might be able to return a type that has __array_interface__ here.

[EchterAgo]

Updated for much better __array_interface__ compatibility from any type implementing it. The normal __array_interface__ is passing a tuple for data that has a pointer and a readonly flag, but PIL for example only passes/expects byte/buffer objects there. In write_barcode we also pass a buffer in data instead of a pointer, which is something I want to change. data seems to also be optional, so I think we could leave it out.

This still needs to be cleaned up a bit and I'm not sure it is worth adding over just the standard buffer protocol support.

[axxel]

Thanks for working on this and bringing us closer to getting rid of the numpy dependency. I like the array_interface approach but if I understand this correct, we might still have an API breakage issue, right? Do you know if there is something like an implicit casting on the Python side happening when someone would try to pass the returned object to a function that takes a numpy array as parameter?

[EchterAgo]

Thanks for working on this and bringing us closer to getting rid of the numpy dependency. I like the array_interface approach but if I understand this correct, we might still have an API breakage issue, right? Do you know if there is something like an implicit casting on the Python side happening when someone would try to pass the returned object to a function that takes a numpy array as parameter?

Yes, this breaks the API. Sadly there is no implicit cast:

>>> data = b'abcdefg'
>>> import numpy as np
>>> mvdata = memoryview(data)
>>> np.array(mvdata)
array([ 97,  98,  99, 100, 101, 102, 103], dtype=uint8)
>>> def test(a: np.array):
...    print(a)
... 
>>> test(mvdata)
<memory at 0x00000205FF1AD6C0>

This still works when passing it to other libraries that handle buffer protocol or array interface internally, in some code it would need an explicit construction of a numpy array, PIL Image or similar though.

[EchterAgo]

I don't really understand Cython enough to do a proper test with it yet, so I removed it from the TODO.

[EchterAgo]

If there is no documentation to adjust, I think this is ready.

[EchterAgo]

I checked README.md, demo_reader.py and demo_writer.py, everything looks good to me.

[axxel]

Will squash and merge once the CI checks are done. Vielen Dank Axel.

[EchterAgo]

Super, vielen Dank auch an dich, Axel!