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.
SceneContents.FOR() uses it as an argument. Wasn't caught by the doc
generator, and looks like it didn't break testing either, probably
because this is an overloaded function and when an overload gets picked,
the types are already defined. Or something. Not sure.
This now causes construction of SceneFieldData from a 2D view to do
`import numpy` internally because of some extremely crazy internal
behavior (as shown in the now-deleted comment in the code). Turns out
everything still works even without marking the types implicitly
convertible from py::array (as it should, anyway), so I suspect that was
only needed long time ago for some strange reason, or maybe on some
older and no longer supported pybind11 version.
This reverts commit eb6576c6af.
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.
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.
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.
The time saved on not writing those messages back then was really not
worth the time wasted on figuring out what the hell every time one of
these fires.
And yet, somehow Python itself and a ton of libraries raises just an
IndexError alone, with nothing saying *how* wrong it was. Those details,
present in Magnum's own C++ asserts, proved to be extremely valuable for
being able to quickly figure out what's wrong, often even without even
having to look at the code or step through in the debugger.
Also fixes an issue where SceneData.field_object_offset() was rejecting
offsets right at the end of the field. Wasn't caught by tests because
apparently LookupError is a base of IndexError and as there was no
message it just failed elsewhere without being noticed.
Also expand the math function tests to explicitly test both the integer
and float variants. Yes, I should have exposed Containers::Pair directly
instead of doing this. No time.
Vladimír Vondruš