 marked as minor
 marked as enhancement
Better support for numpy types.
I find that certain numpy types work while others don't. For example, doing something like ws['A1'] = np.int32(1) causes bind_value to throw a ValueError exception, while ws['A2'] = np.float(1) works. Similarly, ws['A3'] = np.bool(True) also throws an exception.
Maybe numpy could be an optional dependency, and if it is installed then numpy types could be added to the list of types _bind_value checks against?
Comments (9)


reporter The workaround I came up with right now is to convert my numpy types to native python types using np.asscalar, but thats causing a significant slow down. Looking at openpyxl/compat/numbers.py it seems that all that needs to be done is wrap numpy import in a tryexcept and then add the numeric types here to NUMERIC_TYPES.

reporter try: import numpy as np NUMPY_NUMERIC_TYPES = (np.int_, np.intc, np.intp, np.int8, np.int16, np.int32, np.int64, np.uint8, np.uint16, np.uint32, np.uint64, np.float_, np.float16, np.float32, np.float64, np.complex_, np.complex64, np.complex128) NUMERIC_TYPES += NUMPY_NUMERIC_TYPES except ImportError: pass
Something similar needs to be done for np.bool_

Sorry, please either submit a pull request (with tests) or close the issue. See https://bitbucket.org/openpyxl/openpyxl/pullrequests/102/ for further information.

@sheshu The reason that your exceptions are happening for some cases and not others is that
np.float_
andnp.float64
are subclasses of builtinfloat
. Similar fornp.int_
,np.intp
, and one of the other int types. Builtinbool
is also a subclass ofint
.I am trying to figure out a way of including the other numpy types via subclassing, without creating the
try...except
block. 
At most, you would need to add
np.bool_, np.integer, np.floating
. If you want complex support (which I don't think is supported ATM), replacenp.floating
withnp.inexact
. 
I don't think there's any way around a
try…except
clause for an optional dependency. But other parts of the system are important such as times and dates, which need to get cast to Excel serials. Then we need to check the string representation: currently "%.16g" is used. There is no need in more precision because Excel doesn't have it. 
Issue
#519was marked as a duplicate of this issue. 
 changed status to resolved
Add support for NumPy types. Resolves
#595→ <<cset 2762da9e2146>>
 Log in to comment
Numpy support would be nice if someone is prepared to do it. See the rejected PR for some context.