You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
Repository navigation
TST: test_info_preserved_pickle_copy_init failed on s390x with TypeError: data type 'void40' not understood #11339
________________ test_info_preserved_pickle_copy_init[ndarray] _________________
mixin_cols = OrderedDict([('i', <Column name='i' dtype='int64' format='{0}' description='d' length=4>
0
1
2
3), ('a', <Column name=..., ('m', NdarrayMixin([(7, b'a'), (8, b'b'), (9, b'c'), (9, b'c')],
dtype=[('f0', '<i4'), ('f1', 'S1')]))])
def test_info_preserved_pickle_copy_init(mixin_cols):
"""
Test copy, pickle, and init from class roundtrip preserve info. This
tests not only the mixin classes but a regular column as well.
"""
def pickle_roundtrip(c):
return pickle.loads(pickle.dumps(c))
def init_from_class(c):
return c.__class__(c)
attrs = ('name', 'unit', 'dtype', 'format', 'description', 'meta')
for colname in ('i', 'm'):
m = mixin_cols[colname]
m.info.name = colname
m.info.format = '{0}'
m.info.description = 'd'
m.info.meta = {'a': 1}
for func in (copy.copy, copy.deepcopy, pickle_roundtrip, init_from_class):
m2 = func(m)
for attr in attrs:
if (attr != 'dtype'
or getattr(m.info.dtype, 'isnative', True)
or func in (copy.copy, copy.deepcopy)):
original = getattr(m.info, attr)
else:
# func does not preserve byteorder, check against (native) base type.
original = m.info.dtype.name
> assert getattr(m2.info, attr) == original
E TypeError: data type 'void40' not understood
astropy/table/tests/test_mixin.py:450: TypeError
Very likely the culprit is indeed #11294. I think the problem may be in the test, that we use a <i4 input and then expect the output to be consistent also on a big-endian system.
Very likely the culprit is indeed #11294. I think the problem may be in the test, that we use a <i4 input and then expect the output to be consistent also on a big-endian system.
Well, we didn't. arrayswap has an explicitly non-native i4 dtype and is correctly expected to be returned as native (dtype('int32') == dtype('=i4')) – should work here with using newbyteorder() as well, but I believe the real problem is rather the dtype='<i4,|S1') in ndarray, which appears to be encapsulated in such a way that it does survive in original byteorder even on big-endian systems.
Activity
mhvk commentedon Feb 22, 2021
Very likely the culprit is indeed #11294. I think the problem may be in the test, that we use a
<i4input and then expect the output to be consistent also on a big-endian system.pllim commentedon Apr 12, 2021
Is this something that needs to be fixed for 4.3? cc @dhomeier
mhvk commentedon Apr 13, 2021
Possible fix in #11543.
dhomeier commentedon Apr 13, 2021
Well, we didn't.
arrayswaphas an explicitly non-nativei4dtype and is correctly expected to be returned as native (dtype('int32') == dtype('=i4')) – should work here with usingnewbyteorder()as well, but I believe the real problem is rather thedtype='<i4,|S1')inndarray, which appears to be encapsulated in such a way that it does survive in original byteorder even on big-endian systems.