Fix VOTable integer columns with units being cast to float in QTable - #20248

Set the preserve_quantity_dtype table attribute when converting a VOTable to an astropy table

1. Where the cast happens

io.votable itself was never lossy. TableElement.to_table() returns a Table whose columns hold the exact integer values from the file. The cast happens afterwards, in QTable._convert_col_for_table(), which turns any Column with a unit into a Quantity — and Quantity.__new__ defaults to dtype=np.inexact. Since the reader is registered for Table, the unified I/O layer produces the QTable itself, with out = cls(out, copy=False) in table/connect.py, well after the reader has returned.

That is why the fix cannot be a change to the values or dtypes the reader produces — they are already right. What the reader has to do is tell the eventual QTable conversion to leave the dtype alone, and the only channel that survives from the reader to that conversion is the table meta.

2. Implementation

Four lines in TableElement.to_table(), in astropy/io/votable/tree.py:

+# The FIELD ``datatype`` attribute is authoritative, so an integer column that
+# also has a unit must not be silently cast to float when this table is
+# converted to a `~astropy.table.QTable`. This sets the QTable
+# ``preserve_quantity_dtype`` table attribute, which is stored in the meta.
+meta["__attributes__"] = {"preserve_quantity_dtype": True}
+
 table = Table(self.array, names=names, meta=meta)

preserve_quantity_dtype is the TableAttribute added in #20247; like every TableAttribute its value lives in meta['__attributes__'], which is documented behavior of TableAttribute rather than an internal detail being poked at.

This goes in to_table() rather than in connect.py::read_table_votable() so that it also covers code that goes through the votable API directly:

t = parse(fileobj).get_first_table().to_table()
QTable(t)["object_id"].dtype     # int64

That is the path pyvo and astroquery use — DALResultsTable.to_qtable() in the issue report — so fixing only the unified-I/O entry point would have left the reporter's actual call broken.

3. Testing

Two tests in astropy/io/votable/tests/test_table.py, built on a VOTABLE_INT_WITH_UNIT sample modeled on the file in the issue: object_id is datatype="long" unit="NA" with a VALUES null, counts is datatype="long" unit="ct", ra is datatype="double" unit="deg".

• test_qtable_preserves_int_datatype — object_id and counts are int64 and ra is float64; the object_id values compare equal to the exact Python ints; counts keeps u.count; the attribute reads back as True; and a plain Table read of the same bytes is unchanged, since it was never affected.
• test_qtable_preserves_int_datatype_round_trip — writing the QTable back to VOTable and re-reading keeps int64 and the exact values.

Two things worth knowing if you touch these tests: reading unit="NA" emits nothing, but writing it back does emit W50: Invalid unit string 'NA', so only the write is wrapped in pytest.warns. And unit="count" is not valid VOUnit — it parses to UnrecognizedUnit, so the sample uses ct.

Also checked by hand against the file from the issue:

astropy/io/votable, table, io/ascii, io/misc, units, utils, plus docs/table and docs/io doctests: 10522 passed, 206 skipped, 29 xfailed.

4. Trade-offs and what is not addressed

Every table from to_table() now carries meta['__attributes__'] = {'preserve_quantity_dtype': True}, whether or not it has an integer column with a unit. This is visible in t.meta and propagates to formats that preserve meta — an ECSV written from a VOTable-read table gains a __attributes__: {preserve_quantity_dtype: true} line. Writing back to VOTable drops it, since TableElement.from_table() reads only the ID/name/ref/ucd/utype/description keys.

The alternative is to set it only when a column actually is an integer with a unit, which keeps meta clean in the common case. I went with the unconditional form because the guarantee comes from the format — VOTable always declares datatype — rather than from the contents of a particular file. Easy to change if reviewers prefer the narrower version.

Not addressed here, from the issue discussion:

• unit="NA" still parses to an UnrecognizedUnit and the column still becomes a Quantity. The suggestion of skipping the Quantity conversion entirely for UnrecognizedUnit columns is a table change with wider consequences, and is independent of the dtype question — with this PR the values are correct either way.
• No warning is emitted when a unit string fails to parse on read. That behavior is unchanged.