esoteric python number should be supported in constructors from tuples

[jimy-byerley]

Hello @Zuzu-Typ I've noticed a strange behavior of the glm constructors: they accept all kind of numbers when creating a glm type from separated components, but only the native python floats when converting a tuple to a glm type.

>>> import glm
>>> import numpy as np

# native python floats
# working as separate arguments
>>> glm.vec2(1., 2.)
vec2( 1, 2 )
# working in a tuple
>>> glm.vec2((1., 2.))
vec2( 1, 2 )

# esoteric python floats (in this example, numpy floats)
# working as separate arguments
>>> glm.vec2(np.float32(1.), np.float32(2.))
vec2( 1, 2 )
# not working in a tuple
>>> glm.vec2((np.float32(1.), np.float32(2.)))
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
TypeError: invalid argument type(s) for vec()

invalid argument type(s) for vec()

The same occurs with np.float* and np.*int*

While working with numpy and glm together, it's quite common to have numpy return values we want to use as vectors (such as array or image coordinates, or dtype structure fields), so supporting creating vectors from tuple of esoteric numbers could be of some help

For now my workaround is

p = np.unravel_index(np.argmax(...))  # the result is of type (np.uint64, np.uint64)
p = (int(p[0]), int(p[1]), int(p[2]))  # convert each component manually
# then later
some_expression(vec3(p))

# instead of
p = uvec3(np.unravel_index(np.argmax(...)))

Do you think the support for this could be added to the glm constructors ?

[avdstaaij]

Python's unpacking operator (*) can also be used as a workaround:

>>> import numpy as np
>>> from glm import vec2

# Tuple float-like numbers
>>> t = (np.float32(1.), np.float32(2.))

# Construct using the unpacking operator
>>> vec2(*t)
vec2( 1, 2 )

[jimy-byerley]

of course it can, but less ergonomic and computationnaly efficient than just supporting tuples