Repository navigation
Conversation
So far QTable has been much more stringent about the unit format than units.Unit. For example, units such as km.s**-1 are not recognized by QTable even though Unit is able to parse them just fine. As a result QTable does not convert columns with such units into Quantities even though it should. This update fixes the issue by making use of the unit parsing capabilities that Unit already has.
|
Thanks! Would need to add a test to address the missing coverage and also add a change log. |
mhvk
left a comment
There was a problem hiding this comment.
In principle, this looks good (though I managed two comments...) but most important is to add a test case that currently fails and that is fixed by this PR.
I ask in particular since I am surprised this is really needed: q_cls should either be Quantity or a subclass, and those already pass the unit through Unit. So, if it fails, it may also be that there is a bug in units instead of here...
| return has_info_class(col, MixinInfo) | ||
|
|
||
| def _convert_col_for_table(self, col): | ||
| from astropy.units import Unit |
There was a problem hiding this comment.
You can just add Unit to the line from astropy.units import Quantity, QuantityInfo at the top.
| # We need to turn the column into a quantity, or a subclass | ||
| # identified in the unit (such as u.mag()). | ||
| q_cls = getattr(col.unit, '_quantity_class', Quantity) | ||
| qcol = q_cls(col.data, col.unit, copy=False) |
There was a problem hiding this comment.
I would change this to Unit(col.unit) and omit the try/except.
There was a problem hiding this comment.
Unit(col.unit) does not fix the problem, the intermediate conversion to a string is necessary.
If Unit() cannot parse the unit then it will throw a ValueError. The try/except statement ensures that if this happens the code will revert to the old behavior. Omitting try/except could make some files unreadable.
|
Hello @eerovaher 👋! It looks like you've made some changes in your pull request, so I've checked the code again for style. There are no PEP8 style issues with this pull request - thanks! 🎉 Comment last updated at 2020-10-01 14:56:30 UTC |
|
It looks like I had not quite understood the nature of the problem. The columns do get converted to Quantities, but in the cases relevant for this pull request the unit of the resulting Quantity is an UnrecognizedUnit instance, which makes the Quantity instance rather useless. This pull request does ensure the expected behavior both when existing Tables are converted to QTables and when the QTable.read() method is invoked. I believe that these two are by far the most frequent cases where the issue might pop up, so in practice the solution could be considered satisfactory. If you agree, then I will write up the changelog entry. But the actual problem might be in unit parsing done in the Quantity constructor instead. |
|
@eerovaher - I can see how your solution works, but I think it papers over the real bug, that by the time So, the problem would seem to be higher up. One can trace it back with: Tracing it back, the file is read by |
|
Continuing from the above, I think this is not an issue with p.s. It may be better to start a new issue, since I think it is clear that the solution proposed here attacks the problem at the wrong level - though we should definitely keep the test! |
|
@tboch, @tomdonaldson, @pllim - just to be clear, I think the case that this PR tries to solve is how to read a VOtable file with non-compliant but otherwise quite obvious to understand units in such a way that the units are regular ones, not |
|
I would say anything that isn't supported at http://www.ivoa.net/documents/VOTable/20191021/REC-VOTable-1.4-20191021.html#ToC29 and http://www.ivoa.net/documents/VOUnits/ (PDF) should not be supported here, but I'll have to defer to @tomdonaldson and @tboch . Disclaimer: Haven't had time to see if the offending unit string is really supported or not. |
|
I think the unit is not supported, otherwise the file wouldn't be called My sense is that inside |
|
The _get_default_unit_format() function in Should I revert the changes made to the |
|
@eerovaher - that indeed seems the right place! My sense would be to make a new PR - though I'd definitely keep your added test. We for sure want to be able to read GAIA VO tables! |
|
Re: #10786 (comment) Note for devs: |
|
While the problem this pull request was meant to address is real, the solution proposed here is a workaround, not a bug fix. I have opened the issue #10791 for the actual underlying problem. Furthermore, the test added in this pull request is in conflict with this test, so it looks like this pull request can be closed without merging anything. |
|
Closing per comment above from @eerovaher. |
So far QTable has been much more stringent about the unit format than
units.Unit. For example, units such as km.s**-1 are not recognized by
QTable even though Unit is able to parse them just fine. As a result
QTable does not convert columns with such units into Quantities even
though it should. This update fixes the issue by making use of the unit
parsing capabilities that Unit already has.