Repository navigation
Include units in Table column descriptions #756
Description
This was discussed briefly in #683 - it would be nice if the basic 'ascii' output from Table also included units information, when present. E.g., writing a table with t.write('filename', format='ascii') where the columns have units should give something like:
#distance time
#meter second
1.2 3.4
5.6 7.8
Activity
eteq commentedon Feb 11, 2013
I tentatuively assigned this to @taldcroft as our
tablemaster, but if someone else wants to take it on (or @taldcroft has other priorities), I can un-assignembray commentedon May 2, 2014
This is sort of subsumed by astropy/astropy-APEs#7--if/when something like that happens this will be resolved.
taldcroft commentedon May 2, 2014
@eteq - are you OK closing this? As written this issue basically requests inventing a new ASCII table format and (admittedly simple) serialization of table / column meta. I agree with @embray that APE6 will supercede this and produce files that are (more-or-less) human readable and also machine readable.
eteq commentedon May 7, 2014
Hmm... @taldcroft, I guess the question is what happens if APE6 does not go through? Then this is still an issue if I want to round-trip units (which is much more important if we can get
Table/Quantityinteraction working).So I'm perfectly happy to close it when/if APE6 gets merged as it is indeed superceded completely in that case. But perhaps it should be left until then?
taldcroft commentedon May 7, 2014
@eteq - we can leave this open if you want at the conceptual level of wanting unit values to be serialized in some ASCII format. As far as the actual format that was proposed, I would argue strongly against implementing that exact format, so that was the sense in which I thought it should be closed. Either way.
Even though I've taken a break from APE6 for the 0.4 stuff, it is still a very high priority and I am pretty confident that something will get done which supercedes this.
astrofrog commentedon Aug 19, 2014
@taldcroft - I'd like to request that we still try and have something in addition to APE6. What would be nice is if each reader/writer had an extra option that gave it the ability to add a row with units. We're not talking about adding a new format here, just an option for e.g. the basic reader.
astrofrog commentedon Aug 19, 2014
Basically, given a table with units, it should really be possible to write out a table like @eteq is suggesting.
taldcroft commentedon Aug 19, 2014
@astrofrog - are you talking about an extra data row with units or a list of commented lines as in the example from @eteq?
astrofrog commentedon Aug 19, 2014
Basically an extra header line with the units. If the header is using
#as a starting value, then sure.astrofrog commentedon Aug 19, 2014
See #2869 for an example for fixed width tables
eteq commentedon Sep 11, 2014
@taldcroft @astrofrog - thinking about this a bit more, I would also consider this closed if we implement something like what's discussed in #2869 for fixed with tables. I.e., a format where the units are encoded in the name (in a way that astropy can then read back in correctly). Practically, that's just as good as the example I gave in the original post for this issue.
taldcroft commentedon Nov 25, 2019
From @eteq:
APE6 and ECSV are merged and well-established now. Do you think there is a still a need to create a new ASCII table format that puts units in the second line of a fixed-width table?
taldcroft commentedon Nov 25, 2019
Well, I realized that I just closed #4743 as a dup of this one, so maybe it needs to stay open? Or reopen that one and close this?
adrn commentedon Apr 12, 2021
IMO, trying to impose a standard for writing/reading units from plain ascii tables is not worth it and will be violated by free-floating ASCII tables more often than it is supported. So, given that ECSV is an option now, I would vote to close this issue.
eteq commentedon Apr 12, 2021
I think I agree with @adrn here, so I'm going to close this. Note there's a more focused version of this issue I'm still interested in, but I'll make a separate issue and link to here since it's more actionable.