summaryrefslogtreecommitdiff
path: root/numpy/core/arrayprint.py
diff options
context:
space:
mode:
authorErik M. Bray <embray@stsci.edu>2015-10-08 17:33:02 -0400
committerErik M. Bray <erik.bray@lri.fr>2016-05-31 16:30:48 +0200
commit0bf907ac5ed0d3c3917cd55d0511633ea8feb8f3 (patch)
treeab094fcb6738f818bb3f5bfdd573d13f02a59f35 /numpy/core/arrayprint.py
parente6593fbe72d28929345370696ea292a394795089 (diff)
downloadnumpy-0bf907ac5ed0d3c3917cd55d0511633ea8feb8f3.tar.gz
BUG: Fix numerous bugs related to zero-width string arrays (#473, #1901, #2196, #2585, #4955)
PyArray_NewFromDescr normally does not allow zero-width string dtypes (or rather, it automatically converts them to 1-width strings). This affects any code that uses PyArray_NewFromDescr, which is a lot. So we extend PyArray_NewFromDescr_int to allow disabling this functionality in a couple narrow cases where it's appropriate--one is when extracting a field from a structured array that has a zero-width string dtype (which, intentionally or not, has been allowed). The other, which is related, is returning a view of an array that has a zero-width string dtype. This shouldn't otherwise break or change any existing behavior. Remove roadblocks to creating structured dtypes with zero-width fields using dict-based constructors (this was possible by other means such as the list-based constructor--with the previous fix in particular it should not be necessary to block this anymore). Adds tests based on the tests cases given in the issues this is fixing. Fix a bug with array to zero-width array assignment revealed by the tests. I am slightly concerned that the blunt-force check for this in raw_array_assign_array may be masking a bug somewhere else though.
Diffstat (limited to 'numpy/core/arrayprint.py')
0 files changed, 0 insertions, 0 deletions