After much suffering and hunting irrelevant issues I discovered that
with Python 3.8 the PATH is no longer taken into account when looking
for DLLs on Windows, and thus all my module imports fail with the most
extremely anger-inducing nondescript trash message ever:
ImportError: DLL load failed while importing utility: The specified module could not be found.
Fortunately, I have been already doing a very nasty hardcoding operation
for this very problem, for the prebuilt tools, so all that was needed
was turning that into something nicer the user can have control over.
The code takes a py::handle, yes, but for Python itself that's something
completely unknown. Since 2.12, pybind11 reports those as an object
instead, which is a lot better.
This was originally added in d6fec89dc5 as
a doc-generation-only hack, but other tools such as stub generation may
need similar special cases, so it's now a env var check in the binding
generation directly.
It's not a check in every invocation because that *feels* slow (although
pybind11 itself likely does a lot more nasty string comparisons, hashmap
lookups and linked link traversal than that), so if such an env var was
defined while importing the module, the current() is then forever
broken, until interpreter restart.
Yay, finally it's (almost) possible to create custom meshes from pure
Python. Except that there always has to be some initial mesh to add
attributes to, and it's not yet possible to supply index data there.
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.
If enabled, this causes sys.setdlopenflags() being called with
RTLD_GLOBAL before the native Corrade module is loaded, in a hope to
resolve recurring nightmares with static Corrade and Magnum libraries
being linked into multiple dynamic modules.
Originally those were assertions that were kept even in release builds,
which meant that calling math.angle() on non-normalized vectors aborted
the whole Python interpreted. Not great. But then the assertions were
made debug-only, which means invalid usage from Python (where the
bindings are usually only built as Release) now silently gives back a
wrong result, which is perhaps even worse.
Because the Python overhead is already massive due to all string lookup
and such, doing one more check in the implementations isn't really going
to slow down anything. Thus I'm mirroring all (debug-only) Magnum
assertions on the Python side, turning them into exceptions. With proper
messages as well, because those are extremely useful.
Vladimír Vondruš