Skip to content

Have basic ascii table writing include units if they are present #11528

Closed

Description

@eteq

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".

Activity

  1. taldcroft commented on Apr 16, 2021

    @taldcroft
    Member

    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?

  2. embray commented on Apr 22, 2021

    @embray
    Member

    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.

  3. taldcroft commented on Apr 22, 2021

    @taldcroft
    Member

    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.

  4. hamogu commented on Feb 27, 2026

    @hamogu
    Member

    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.

  5. added
    Close?Tell stale bot that this issue/PR is stale
    on Feb 27, 2026
  6. taldcroft commented on Mar 2, 2026

    @taldcroft
    Member

    Agreed to close this and I added the wont-fix label.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions