Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add case (in)senstive option to registry and extend to Unit and Quantity parsing #1145

Closed
jthielen opened this issue Aug 14, 2020 · 2 comments · Fixed by #1147
Closed

Add case (in)senstive option to registry and extend to Unit and Quantity parsing #1145

jthielen opened this issue Aug 14, 2020 · 2 comments · Fixed by #1147

Comments

@jthielen
Copy link
Contributor

In our quest to handle CF compliant/UDUNITS style units in MetPy, we have come across a couple issues regarding case sensitivity. For example, we need to be able to parse Meter as meter and Celcius as an alias of degrees_Celcius. To enable this within Pint (as an option of course and not the default to maintain standards), I would like to propose the following to extend the case insensitive handling already existing in Pint:

  1. Add a case_sensitive option to BaseRegistry which defaults to True
  2. Modify the existing case_sensitive options on get_name, parse_unit_name, parse_pattern, and parse_expression to default to None instead of True, and have None be replaced within the methods with the registry's case_sensitive option
  3. Add analogous case_sensitive kwarg to parse_units
  4. Optional: add analogous case_sensitive kwarg to any other public registry method that ends up using parse_unit_name (or something that uses it, recursively) so that it can be appropriately passed along.

This would allow something like the following to become valid, so that a greater extent of CF unit compliance can be achieved:

import pint

ureg = pint.UnitRegistry(case_sensitive=False)

q = ureg("1 Meter")

print(q)
1 meter

@hgrecco Is this compatible enough with your philosophy for Pint in #1081 (comment) and seem like a reasonable enough way forward in implementation?

@hgrecco
Copy link
Owner

hgrecco commented Aug 14, 2020

Thanks @jthielen for the comprehensive and clear proposal. I think that your solution covers all major points and the suggetsted defaults are good not only to adhere to pint philosophy but also to maintain backwards compatibility. I also agree with point 4.

I will be happy to review and merge this PR when ready.

@jthielen
Copy link
Contributor Author

Thanks @jthielen for the comprehensive and clear proposal. I think that your solution covers all major points and the suggetsted defaults are good not only to adhere to pint philosophy but also to maintain backwards compatibility. I also agree with point 4.

I will be happy to review and merge this PR when ready.

Sounds great, thanks! I'll add this to my queue of PR's to work on across projects the next couple days.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants