Unit('0') prints NULL factor argument and NULL unit argument

[schlunma]

🐛 Bug Report

While reading lots of large netCDF files with iris, I noticed that my entire stderr is cluttered with the following prints:

ut_scale(): NULL factor argument                                                                                                                                                                                                                                             
ut_are_convertible(): NULL unit argument

These come from the use of cf_units.Unit('0') for variables with the unit '0'.

How to Reproduce

Steps to reproduce the behaviour:

Using

from cf_units import Unit
Unit('0')

correctly raises an error, but also prints the messages mentioned above:

ut_scale(): NULL factor argument
ut_are_convertible(): NULL unit argument
Traceback (most recent call last):
  File "/home/b/b309141/tmp/iris_warning.py", line 3, in <module>
    Unit('0')
  File "/work/bd0854/b309141/mambaforge/envs/esm/lib/python3.10/site-packages/cf_units/__init__.py", line 839, in __init__
    raise value_error from None
ValueError: [UT_SUCCESS] Failed to parse unit "0"

These warnings cannot be suppressed using python -W ignore or by using warnings.filterwarnings.

Expected Behaviour

These warnings should not be printed or be issued using the warnings module so they can be handled properly.

Environment

• OS & Version: Red Hat Enterprise Linux 8.4
• cf-units Version: 3.0.1

[bouweandela]

After looking around in the code a bit, I found that you can use the undocumented function suppress_errors to stop the warnings from being printed:

from cf_units import Unit, suppress_errors
with suppress_errors():
  Unit('0')

[rcomer]

Looks like there are a few undocumented yet public functions in there (e.g. is_vertical, is_time). Maybe we just need to add a new section to the docs?

[bouweandela]

The current default behaviour of printing to stderr if something goes wrong seems odd for a library, because there is no standard way in which users of the library can do something with that information. I agree with @schlunma that it would be better to use the warnigns module for that (or a logger).