Otherwise people wouldn't be able to conveniently use os.path, which is
an undesirable pain point. And do this for all currently exposed APIs,
not just the AbstractImporter that caused a problem.
This reverts commit 28497ec2ca.
Because for some reason pybind11 on *some platforms* (or in some
configurations?) picks the integer overload even for enum arguments,
only because it's first in the overload set.
This is extremely brittle, but for now I don't know any better solution.
In concrete types. Yes. Well, some of them for now, I still need to
sleep on normalized and matrix types, how it makes the most sense to
expose those. Oh, and array attributes as well.
Because making & testing my own string caster is not something I'd want
to do right now (seems complicated by looking at what's all done for
std::string), the functions currently all go through a std::string
instead.
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.
Pybind changed py::module to py::module_ in order to support C++
modules, adapting to that change. It still builds on older versions,
but we're using only the new APIs.
That makes it much easier to handle in that case (because that's the
whole point of static builds) and also nicely circumvents any issues
with duplicated global data when a static lib would be linked to
multiple dynamic libraries.
Only the double ones, exposed as floats, because the extra ALU required
by doubles is negligible to function call overhead. It'll be different
for non-scalar types, but here I use this.
Vladimír Vondruš