Adam Hillier

I guess that's my question then: assuming that we don't allow key insertion, why would the current approach be suboptimal? Another question I have is how subclassing would work with...

It would also be good to get some nice colour coding which shows which parameters have been overriden through the CLI.

> It probably gets tricky quite quickly and may need to be done in e.g. `__getattribute__`. I definitely agree with the motivation but I think doing this might be tricky,...

We definitely could do a check specifically for `@task`s prior to calling the `run` method. Would that be useful do you think?

> In general I'm usually in favor of having a bit of internal implementation ugliness as a way to support more intuitive/robust/harder-to-break behavior for the end user, so these options...

> If users pass in mutable values via the CLI, we'd implicitely wrap them into a lambda functions to be consistent with how the Python API works. If we have...

> In general having > > ```python > @Field > def input_quantizer(self): > return lq.quantizers.SteSign(clip_value=1.25) > ``` > > behave like `@property` is very intuitive for me, though the same...

> What about using [`copy.deepcopy`](https://docs.python.org/3.8/library/copy.html#copy.deepcopy) in the lambda? Cool, I hadn't come across that before but it looks like it would work. Especially as the values that can be passed...

Okay, so the concrete proposal is that `Field` gains a `cache_value` keyword argument, defaulting to `false`. When set to `true`, `Field` accesses have their current behaviour. When set to `false`,...

> Will the bahaviour of immutable values like numbers change depending on `cache_value`? Unless we require the immutable defaults to be passed in with lambdas we can't really not cache...