Closed richardjgowers closed 8 months ago
Hello @richardjgowers! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:
gufe/settings/models.py
:Line 66:80: E501 line too long (80 > 79 characters)
All modified and coverable lines are covered by tests :white_check_mark:
Comparison is base (
ae96d30
) 99.20% compared to head (ecd7fa7
) 99.11%.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
In [5]: class Foo(BaseModel):
...: temp: FloatQuantity['kelvin']
...:
In [6]: f = Foo(temp='10 K')
In [7]: f
Out[7]: Foo(temp=<Quantity(10.0, 'kelvin')>)
In [8]: f = Foo(temp='10')
---------------------------------------------------------------------------
ValidationError Traceback (most recent call last)
Cell In[8], line 1
----> 1 f = Foo(temp='10')
File ~/mambaforge/envs/openfe_env/lib/python3.10/site-packages/pydantic/main.py:341, in pydantic.main.BaseModel.__init__()
ValidationError: 1 validation error for Foo
temp
Cannot convert from 'dimensionless' (dimensionless) to 'kelvin' ([temperature]) (type=type_error.dimensionality; units1=dimensionless; units2=kelvin; dim1=dimensionless; dim2=[temperature]; extra_msg=)
@dwhswenson I'm not sure we have to be worried about stray strings on Quantities. It will only "work" if the string is also valid as a Quantity, so not paths, and simple ints/floats are not "upcasted" into Quantitie.
I think you're rightly worried about bad variable names here (temperature is much better than temp for example), but that's not really made much worse by this feature
@richardjgowers : You've got the mistake I'm concerned about backwards. I'm worried about stray "quantities" on strings (when given as string). If I thought temp
controlled temperature, but it actually controlled a tempfile name, I could easily do this:
In [1]: from pydantic import BaseModel
In [2]: class Foo(BaseModel):
...: temp: str = "tempfile.dat" # a filename
...:
In [3]: f = Foo(temp="10 K")
In [4]: f
Out[4]: Foo(temp='10 K')
That works just fine, and could lead to confusion and even incorrect science. Sure, it is user error, but we're giving them the gun and making it easier to point it at their foot.
EDIT: To clarify, I'm not worried about this specific thing happening. I'm more worried about the general idea that, even with typing differences, we risk errors. Much more likely is that somebody thinks a parameter has some name (e.g. gamma) when in that case the developer called it alpha, and some other setting has a parameter called gamma. Typing won't save you here, but namespaces (nested settings) will.
fixes #254
Adds SettingsBaseModel.find_field and set_field to find and set a parameter name from anywhere within the nested Settings