Currently the mapping of formats that xtgeo accepts are kept as a dict and referenced only in XTGeo's custom file class. However, the keys of this dict are used in many places when operating on files -- but not directly, just as strings, like so for example
where every _fformat in ("egrid", "fegrid")-type conditional is checking which key in the supported formats dict _fformat represents. That is, _fformatis a key in this dict that has earlier been returned from a method in the XTGeoFile class, but this isn't clear because we treat them as strings internally.
It might make things more maintainable to turn this SUPPORTED_FORMATS dict into an enum and replace the Literals we have established throughout the code with the enum keys. Users can still provide file extensions or types as strings when opening or writing files, but these should map to the enum whereafter the enum key is used internally.
Currently the mapping of formats that xtgeo accepts are kept as a dict and referenced only in XTGeo's custom file class. However, the keys of this dict are used in many places when operating on files -- but not directly, just as strings, like so for example
https://github.com/equinor/xtgeo/blob/87e7acfdfd165599e501d2822fe531e11c4a6d6c/src/xtgeo/grid3d/_grid_import.py#L52-L70
where every
_fformat in ("egrid", "fegrid")-type conditional is checking which key in the supported formats dict_fformatrepresents. That is,_fformatis a key in this dict that has earlier been returned from a method in the XTGeoFile class, but this isn't clear because we treat them as strings internally.It might make things more maintainable to turn this SUPPORTED_FORMATS dict into an enum and replace the
Literals we have established throughout the code with the enum keys. Users can still provide file extensions or types as strings when opening or writing files, but these should map to the enum whereafter the enum key is used internally.