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
Have basic ascii table writing include units if they are present #11528
This is coming from the discussion whether or not to close #756 - after reading that I realized the one thing still not solved in my original issue description is that when one writes a basic ASCII table when the units are present, those units are lost. I think it is desirable for those units to be written out somehow by default (although it certainly should be an option to not do that, and maybe even the default?).
My thinking here is that users (i.e., some of my collaborators!) just do a quick table.write('filename', format='ascii'), and that drops the units, which is not desirable for cases where the table is relying on the units for important information (most relevant here is tables with "RA" where it's never clear if it's hours vs degrees). So defaulting to having the units written if they're present I think is a Good Thing :TM:. So it should default to something like:
#id RA Dec
#None hour degree
NGC1234 1.2 3.4
NGC9876 9.1 2.3
Note, that, unlike #756, I am not expecting round-tripping here or any standardization. That's already been achieved by ECSV. This is entirely about "human-readable-headers".
I'm not super excited about making this the default since adding commented lines to the ascii.basic format is not without impact and it can break existing code out in the wild. The # comment character is not recognized by default by some readers, notably pandas:
In [1]: import pandas
In [2]: cat junk.dat
id RA Dec
#None hour degree
NGC1234 1.2 3.4
NGC9876 9.1 2.3
In [3]: pandas.read_csv('junk.dat', delimiter=' ')
Out[3]:
id RA Dec
0 #None hour degree
1 NGC1234 1.2 3.4
2 NGC9876 9.1 2.3
If writing the unit line is not the default, then you need to train your collaborators to do something different anyway (add a new show_units=True keyword). At that point just telling them to use t.write('<something>.ecsv') will get the job done.
With 4.3, ECSV will get even better with full support for multidimensional columns. And did you know that ECSV is also supported in TOPCAT now?
When writing tables to a file with the .ecsv extension it will write ECSV. Maybe also for tables with units the default ASCII format should be ECSV even if just a plain .csv extension is used.
Maybe also for tables with units the default ASCII format should be ECSV even if just a plain .csv extension is used.
This has the strong potential for breaking stuff. I think it isn't a good idea to try being too clever and do things that the user did not ask for. Personally I'd be very unhappy if I told astropy write pure CSV and I got ECSV instead.
I agree with @taldcroft and thus suggest to close this issue.
There are plenty of ways to preserve that information (ecsv is one, but votable or fits might also work for many cases). Suddenly changing the output format by default in version 8 of astropy is a terrible idea, and even if we didn't care for backwards compatibility, we would then end up with tables that e.g. pandas can't read (writing ecsv by default will cause the same problem as "adding a commented line with units" that some reader do not know how to deal with "#" markers as comments by default.
Activity
taldcroft commentedon Apr 16, 2021
I'm not super excited about making this the default since adding commented lines to the
ascii.basicformat is not without impact and it can break existing code out in the wild. The#comment character is not recognized by default by some readers, notably pandas:If writing the unit line is not the default, then you need to train your collaborators to do something different anyway (add a new
show_units=Truekeyword). At that point just telling them to uset.write('<something>.ecsv')will get the job done.With 4.3, ECSV will get even better with full support for multidimensional columns. And did you know that ECSV is also supported in TOPCAT now?
embray commentedon Apr 22, 2021
When writing tables to a file with the
.ecsvextension it will write ECSV. Maybe also for tables with units the default ASCII format should be ECSV even if just a plain.csvextension is used.taldcroft commentedon Apr 22, 2021
This has the strong potential for breaking stuff. I think it isn't a good idea to try being too clever and do things that the user did not ask for. Personally I'd be very unhappy if I told astropy write pure CSV and I got ECSV instead.
hamogu commentedon Feb 27, 2026
I agree with @taldcroft and thus suggest to close this issue.
There are plenty of ways to preserve that information (ecsv is one, but votable or fits might also work for many cases). Suddenly changing the output format by default in version 8 of astropy is a terrible idea, and even if we didn't care for backwards compatibility, we would then end up with tables that e.g. pandas can't read (writing ecsv by default will cause the same problem as "adding a commented line with units" that some reader do not know how to deal with "#" markers as comments by default.
taldcroft commentedon Mar 2, 2026
Agreed to close this and I added the
wont-fixlabel.