In code review at #910 (comment) I noted that we could replace a tuple defining valid indexing schemes with an equivalent enumeration:
|
return ("nested", "ring", "nuniq", "zuniq") |
We agreed we should at some point survey the codebase systematically for further appropriate places to use enumerations to e.g. make comparisons against well-defined sets of values such as controlled vocabs more robust, clear and type safe.
We already have Enums applied well for a few cases:
|
# -------------------------------------------------------------------- |
|
# Logging level setup |
|
# -------------------------------------------------------------------- |
|
# For explicitness, define here rather than importing identical Enum |
|
# from cfdm |
|
class ValidLogLevels(Enum): |
|
DISABLE = 0 |
|
WARNING = 1 |
|
INFO = 2 |
|
DETAIL = 3 |
|
DEBUG = -1 |
|
|
|
|
|
# -------------------------------------------------------------------- |
|
# Controlled vocabulary for bounds combination options |
|
# -------------------------------------------------------------------- |
|
class OperandBoundsCombination(Enum): |
|
AND = auto() |
|
OR = auto() |
|
XOR = auto() |
|
NONE = auto() |
From a quick look, some further good candidates across the codebase for using these are:
- Also in the
constants module as above: the CF cell methods set, and perhaps the keys from the cr_coordinates dict and the formula coordinate types (atmosphere_sigma_coordinate, ocean_s_coordinate, ocean_sigma_z_coordinate, etc.) both of which appear across multiple dictionaries there (which could in turn be converted to data classes, also an improvement);
- The valid regridding methods, i.e. keys to:
|
esmpy_methods = { |
|
"linear": None, |
|
"bilinear": None, |
|
"conservative": None, |
|
"conservative_1st": None, |
|
"conservative_2nd": None, |
|
"nearest_dtos": None, |
|
"nearest_stod": None, |
|
"patch": None, |
|
} |
- (Upstream in
cfdm*) the valid backends for reading and writing: https://github.com/NCAS-CMS/cfdm/blob/e6ebddb4a0f533f079f7f1ea0da2efdf6595c928/cfdm/read_write/netcdf/netcdfread.py#L1334-L1339 (for netCDF only) and https://github.com/NCAS-CMS/cfdm/blob/e6ebddb4a0f533f079f7f1ea0da2efdf6595c928/cfdm/read_write/netcdf/netcdfwrite.py#L5768 respectively.
* we should consider for all Enums defined whether it is best to define and import them in from cfdm, or have them in cf-python only.
In code review at #910 (comment) I noted that we could replace a tuple defining valid indexing schemes with an equivalent enumeration:
cf-python/cf/functions.py
Line 3501 in 02e348c
We agreed we should at some point survey the codebase systematically for further appropriate places to use enumerations to e.g. make comparisons against well-defined sets of values such as controlled vocabs more robust, clear and type safe.
We already have
Enums applied well for a few cases:cf-python/cf/constants.py
Lines 522 to 542 in 8c760f8
From a quick look, some further good candidates across the codebase for using these are:
constantsmodule as above: the CF cell methods set, and perhaps the keys from thecr_coordinatesdict and the formula coordinate types (atmosphere_sigma_coordinate,ocean_s_coordinate,ocean_sigma_z_coordinate, etc.) both of which appear across multiple dictionaries there (which could in turn be converted to data classes, also an improvement);cf-python/cf/regrid/regrid.py
Lines 20 to 29 in 02e348c
cfdm*) the valid backends for reading and writing: https://github.com/NCAS-CMS/cfdm/blob/e6ebddb4a0f533f079f7f1ea0da2efdf6595c928/cfdm/read_write/netcdf/netcdfread.py#L1334-L1339 (for netCDF only) and https://github.com/NCAS-CMS/cfdm/blob/e6ebddb4a0f533f079f7f1ea0da2efdf6595c928/cfdm/read_write/netcdf/netcdfwrite.py#L5768 respectively.* we should consider for all
Enums defined whether it is best to define and import them in from cfdm, or have them in cf-python only.