-
-
Notifications
You must be signed in to change notification settings - Fork 57
Description
So far, I've been telling people to do pyvo.samp.send_table_to(tap_result.to_table()). Turns or that is a bad idea because it is losing essentially all metadata: PARAMs and INFOs are lost in this way, and that's bad not only since data origin. For instance, it also loses the spectral axis when playing with the Heidelberg sampled XP spectra.
We should therefore tell people to send tap_result.votable.
That doesn't work so far because send_table_to uses "unified I/O", and tap_result.votable doesn't have a write method. Actually, it's the accessible_table context manager that fails. A simple way to enable sending VOTables as such would be:
@contextlib.contextmanager
def accessible_table(table):
"""
a context manager making astropy_table available under a (file)
URL for the controlled section.
"""
handle, f_name = tempfile.mkstemp(suffix=".xml")
with open(handle, "w") as f:
if hasattr(table, "to_xml"):
table.to_xml(f)
else:
table.write(output=f, format="votable")
try:
yield "file://" + f_name
finally:
os.unlink(f_name)
but I suspect the hasattr won't go well with... umm, anyone but me.
What would be wrong with giving VOTable objects a unified I/O-like interface, enough at least so that accessible_table would be happy with it?
Or am I missing a really good solution to this problem? Should we perhaps explain all kinds of service results to send_table_to?