ureg.load_definitions: is_resource parameter is ignored

[tbrugere-nrjx]

here:

pint/pint/facets/plain/registry.py

Line 583 in 28816e1

def load_definitions(

The is_resource parameter is not passed down to _def_parser.parse_file (which cannot take it as input anyway). It’s also not used to read the file, it’s simply ignored

[tbrugere-nrjx]

Should I make a PR ?

[andrewgsavage]

sure

[tbrugere]

Done ! (account switch from my work to my main)

[andrewgsavage]

looking into this further, I am not so sure this should be added. I don't see much when I google is_resource python, and what I do find suggests there aare more modern methods:

https://importlib-resources.readthedocs.io/en/latest/using.html#migrating-from-legacy

Starting with Python 3.9 and importlib_resources 1.4, this package introduced the files() API, to be preferred over the legacy API, i.e. the functions open_binary, open_text, path, contents, read_text, read_binary, and is_resource.

do you have a use case for it?

[tbrugere-nrjx]

I mean I do load a definition file from resources, but currently I simply do the following:

# load unit registry
units_txt = resources.files("mymodule") / "units.txt"
ureg = pint.UnitRegistry(fmt_locale=get_locale(), system="SI")

with units_txt.open() as f:
    ureg.load_definitions(tuple(f))

Note the conversion from file to tuple, because otherwise, it doesn’t get caught by this if:

https://github.com/hgrecco/pint/blob/28816e1f5b22333b9dc11d42258b481379ab2b04/pint/facets/plain/registry.py#L597C1-L597C44

(even though a file is an Iterable[str], so it should work according to the type hints)

[tbrugere-nrjx]

So no, I don’t think it is a very useful parameter to have, since it can just be handled explicitely by the user. But in that case you might want to remove it altogether (or raise a warning if it is passed)