Repository navigation
Parse plural forms of units from strings #1520
Description
I know that we decided to always use singular units in Astropy, but I'm wondering whether we should allow the unit parser to be a little more relaxed - for instance I am reading some files that have units in microns and this is causing the parser to fail:
In [5]: Unit('microns')
ERROR: ValueError: 'microns' did not parse as unit format 'generic': At col 0, 'microns' is not a valid unit in string 'microns' [astropy.units.core]
Do we want to consider relaxing the parser (maybe optionally) for such plural forms?
Activity
astrofrog commentedon Oct 3, 2013
Similarly, do we want to allow capitalized forms if they are unambiguous?
astrofrog commentedon Oct 3, 2013
Another example of unit read in from an existing file
By the way, I'm not saying that we should support all of these, but just raising the question as to whether we should have a non-pedantic mode that recognizes e.g. plural forms and doesn't care about capitalization?
mdboom commentedon Oct 3, 2013
I'm really wary of deviating from the unit standards, of which there are already too many, and I don't want to create another one. Interoperability is really important -- it may sound pedantic and rigid, but any time you extend a format to include extra things, people will be surprised when it doesn't interoperate with other tools. I think the only reason I would do this is if a large, important database provided data in this way and they were unwilling to change. Otherwise, I think we need to stand our ground.
None of the existing unit formats take pluralized names, and all are case sensitive.
mhvk commentedon Oct 3, 2013
I can see a bit of a case for the full names of units ("microns", "meters", "Newtons"), but not for the abbreviations that are defined for it (i.e., no "ergs", "dynes", "bas" [but maybe "barns"]). I agree with @mdboom with being wary of accepting anything like this by default, but perhaps a
format='lax'option would be a useful addition. Overall, still -0.mdboom commentedon Oct 8, 2013
I'd like to push this off to 0.4. Agreed?
astrofrog commentedon Oct 8, 2013
@mdboom - definitely
embray commentedon Oct 11, 2013
I could see a case for "strict=False" mode for parsing units, either implemented as a module level configuration variable or some option on the Unit parser. Obviously "strict=True" should be the default.
mdboom commentedon Dec 5, 2013
I'm going back through some old issues here. I'm still really against making this change, however, what about making something like this work...?
pllim commentedon Dec 5, 2013
Just for the record, STScI has a bunch of spectra files with unit set to
angstroms. I worked around it by having my own little function to recognize that string and set the unit tou.AA. I do agree with @mdboom's solution, because if people want to use non-standard unit string, they should handle it appropriately themselves.embray commentedon Dec 5, 2013
I like this solution.
astrofrog commentedon Dec 5, 2013
+1 to suggestions
mdboom commentedon Dec 30, 2013
Closed by #1870.