Settings setting shortcut thing

[richardjgowers]

fixes #254

Adds SettingsBaseModel.find_field and set_field to find and set a parameter name from anywhere within the nested Settings

[pep8speaks]

Hello @richardjgowers! Thanks for updating this PR. We checked the lines you've touched for PEP 8 issues, and found:

• In the file gufe/settings/models.py:

Line 66:80: E501 line too long (80 > 79 characters)

Comment last updated at 2023-12-12 18:41:51 UTC

[codecov]

Codecov Report

All modified and coverable lines are covered by tests ✅

Comparison is base (ae96d30) 99.20% compared to head (ecd7fa7) 99.11%.

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #255      +/-   ##
==========================================
- Coverage   99.20%   99.11%   -0.10%     
==========================================
  Files          36       36              
  Lines        1898     1919      +21     
==========================================
+ Hits         1883     1902      +19     
- Misses         15       17       +2     

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[dwhswenson]

I'm not keen on this because I'm concerned about synonyms. I can imagine a user thinking they're setting a temperature with settings.temp, but this actually sets a temp file name (especially if they're setting temperature with a string.)

[richardjgowers]

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

[dwhswenson]

@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.