Repository navigation
Description
Description
When trying to write a table with structured columns (having additional dimensions) to an ascii format with a default fast_writer, the latter fails with relatively confusing errors.
Expected behavior
Since the fast writer does not support such dtypes it should either raise an exception clarifying that the 'fast_writer'=False option should be used, or directly fall back to this (with appropriate warning).
Steps to Reproduce
>>> import numpy as np
>>> from astropy.table import Table, Column
>>> t = Table([Column(np.ones(3, dtype=('f', (2,))), name='R')])
>>> t
<Table length=3>
R [2]
float32
----------
1.0 .. 1.0
1.0 .. 1.0
1.0 .. 1.0
>>> t.write('test.txt', format='ascii.basic')
Traceback (most recent call last):
File "<stdin>", line 1, in <module>
File "/opt/lib/python3.8/site-packages/astropy/table/connect.py", line 127, in __call__
registry.write(instance, *args, **kwargs)
File "/opt/lib/python3.8/site-packages/astropy/io/registry.py", line 563, in write
writer(data, *args, **kwargs)
File "/opt/lib/python3.8/site-packages/astropy/io/ascii/connect.py", line 26, in io_write
return write(table, filename, **kwargs)
File "/opt/lib/python3.8/site-packages/astropy/io/ascii/ui.py", line 851, in write
writer.write(table, output)
File "/opt/lib/python3.8/site-packages/astropy/io/ascii/fastbasic.py", line 167, in write
self._write(table, output, {})
File "/opt/lib/python3.8/site-packages/astropy/io/ascii/fastbasic.py", line 181, in _write
writer.write(output, header_output, output_types)
File "astropy/io/ascii/cparser.pyx", line 1125, in astropy.io.ascii.cparser.FastWriter.write
TypeError: unhashable type: 'list'Note that it would probably generally be wise to warn the user about the limited support of such columns in ASCII formats (which will still be written as str columns like "1.0 .. 1.0" by the Python writer), advising them to replace them with individual 1D columns if needed.
See also https://mail.python.org/pipermail/astropy/2020-December/004839.html
Even nicer would of course be a (semi-)automatic "unfolding" functionality for such columns. ;-)
System Details
macOS-10.14.6-x86_64-i386-64bit
Python 3.8.6 (default, Oct 15 2020, 01:14:04)
[Clang 11.0.0 (clang-1100.0.33.17)]
Numpy 1.20.0rc1
astropy 4.2
Activity
taldcroft commentedon Dec 8, 2020
I have thought about adding support in ECSV for N-d columns. In theory one can make column names like
R.0orR.1.2. This would be the right format for such support since there can be appropriate metadata in the file to allow round-trip.Note that ECSV does already detect N-d columns and give a good message, so this can be a template for other readers:
taldcroft commentedon Dec 8, 2020
The code to actually do this is probably not that difficult using the serialization protocols in place for mixin columns. Instead of a
SkyCoordthat writes out columns likesc.raandsc.dec, you haveColumnknow that it needs to break down into component columns for each sub-dimension.dhomeier commentedon Dec 8, 2020
My suggested workaround to the OP could probably be generalised (for now for
ndim=2) to– which one could at least try and see if any naming conflicts arise, but having the writer handle this directly at the column level is of course much better.
taldcroft commentedon Dec 9, 2020
@dhomeier - good idea to provide a workaround. Here is a generalized version that makes a new table:
dhomeier commentedon Dec 11, 2020
Thanks for the worked-out solution @taldcroft! I had been thinking about adding this as a convenience function, but returning a new table is probably a better option than making potentially non-reversible modifications to the existing one.
Looking for a good place to implement this, I noticed that
to_pandasalso has a similar check inastropy/astropy/table/table.py
Line 3411 in 2388de9
so perhaps this could be added as a
Tablemethod?taldcroft commentedon Dec 11, 2020
I was thinking about a new method also. But in fact what we probably want is to also flatten any mixin columns down to plain columns using represent_mixins_as_columns. Or at least have that option.
astrofrog commentedon Jun 3, 2026
Ok so the original 'bug' is fixed here in the sense there is now a better error message:
but it seems this has now changed to be a feature request for a convenience method to flatten columns?
taldcroft commentedon Jun 3, 2026
Sounds like a good feature which is not too much effort. I think it should flatten structured or multi-dim columns along with represent_mixins_as_columns. The latter is now exposed as a public function. I'll try to have a go at this.
taldcroft commentedon Jul 28, 2026
@astrofrog @dhomeier - please see #20138.