This finally makes it possible to expose APIs that take StridedArrayView
instances as an input, until now the type information was always lost,
making all views plain bytes and thus impossible to check whether the
types passed were a large enough size at least, if nothing else.
Preserving the type means there has to be type-dependent implementation
for __getitem__() and __setitem__(). So far this is only done for the
very basic builtin types, similarly to what Python's own array supports.
In the buffer protocol it used to advertise untyped data with B as the
format string, but the __getitem__ and __setitem__ were using the char
type (implicitly coming from the fact that the type exposed is
ArrayView<char>, StridedArrayViewND<char> or their const variants),
resulting in the data being treated as characters by Python. Which
was extremely annoying and inconsistent with how the bytes and bytearray
behaves.
Now ArrayView bindings always operate with std::uint8_t, and for
StridedArrayView there's a special case for the <char> type, which makes
it treated as std::uint8_t as well. Furthermore, to hint that the <char>
is "general data", the format string for it is null / None instead of B.
Changed those to be IndexError instead of ValueError, since those are
indexing dimensions. Plus added a new check for broadcasted dimension
size as otherwise it'd blow up on a C++ assert.
Need that for configuring plugins -- originally thought I'd wait until
the class is reworked, but that isn't coming anytime soon given there's
insane pressure on other things, so I have to figure out a plan B.
The interface is the most barebones possible, exposing nothing that I'd
later plan to rename or remove. Just the least possible amount of APIs
to make it possible to configure plugins, and no custom type support yet
either -- if you need to write a vector, write it as a formatted string
instead, sorry.
To make it possible to test the APIs in isolation instead of through
the plugin interface, I added also a Configuration class. Also just the
least amount possible to cover the code with tests.
It limits the support for CMake 3.12+, but it's much less verbose and I
don't expect people to use ancient CMake versions with IDEs like Xcode
or VS anyway, so this should be fine.
Not ArrayView yet, and also no documentation on this whatsoever. That'll
come next. Also not everything works with arbitrary types yet,
converting from buffer protocol doesn't remember the format and
conversion to bytes doesn't take the actual type size into account
either.
Vladimír Vondruš