Closed rbeyer closed 3 years ago
Merging #96 (3200cec) into main (f27c43e) will increase coverage by
0.02%
. The diff coverage is100.00%
.
@@ Coverage Diff @@
## main #96 +/- ##
==========================================
+ Coverage 94.97% 94.99% +0.02%
==========================================
Files 12 12
Lines 1929 1937 +8
==========================================
+ Hits 1832 1840 +8
Misses 97 97
Impacted Files | Coverage Δ | |
---|---|---|
pvl/collections.py | 98.71% <100.00%> (ø) |
|
pvl/parser.py | 96.97% <100.00%> (+0.07%) |
:arrow_up: |
Continue to review full report at Codecov.
Legend - Click here to learn more
Δ = absolute <relative> (impact)
,ø = not affected
,? = missing data
Powered by Codecov. Last update f27c43e...3200cec. Read the comment docs.
Description
The strict PVL, ODL, and PDS3 dialects of PVL-text do not allow empty parameters, like so:
However, given the vast amount of broken PVL-text out there, the "Omni" strategy used by default in the loaders, should handle this. In general, it does. However, there was a bug where if the above pattern was present inside a PVL group or object in the middle (at least one regular parameter/value pair after the missing value, as as above) the parsers would go into an infinite loop. If the missing value was for the last parameter in the object or group it did not have this failure mode.
We already have a
parse_module_post_hook()
function that handled this for the general case, and this function is now properly implemented for parameters and values within groups and objects.Also, while I was noticing it, the FutureWarnings on use of
.popitem()
and.pop(k)
were also bleeding through when one was using.pop()
in the "good" way. So some rearranging of this code was done so that the FutureWarning only gets emitted when you're using these functions in the way that might be deprecated in the future.Related Issue
This would close #95.
How Has This Been Tested?
Types of changes
Checklist:
Licensing:
This project is released under the LICENSE.