David Alonso

OK, I see. So I guess we'd want some kind of `_repr_` for the relevant CCL classes that contains enough information to recreate them from scratch.

I don't think there's an easy way to do this right now. It would be great to have HMCode implemented natively (and that would solve this problem). Much of the...

I'd say this is up to the boltzmann solvers, and in that case the Calculator mode solves the issue. Unless others feel differently! Will leave open for a few days...

Just to confirm that I've also come across this, and it seems important enough to be fixed!

After some tinkering, that did the trick. Thanks @lgarrison ! Hope this can be patched soon though!

This is not to be reviewed until existing capabilities have been moved to v3. There is new science implementations that take priority.

I think that's because any subclass of `CCLNamedClass` needs to implement the `name` method (see [here](https://github.com/LSSTDESC/CCL/blob/5022b89e8a89679126de8f917c9a6f3389c7b5b5/pyccl/_core/schema.py#L346))

It was so you can have a `from_name` [method](https://github.com/LSSTDESC/CCL/blob/fda2e0cbe195eafda5226727f4db6b477288f72f/pyccl/_core/schema.py#L357) that you can use with more memorable/meaningful names (e.g. `ccl.MassFunction.from_name("Tinker08")`). I agree it may be a bit superfluous, since modern IDEs...

It may be interesting to save delta, phi+psi and at some point, v (the latter two for lensing and RSDs). These are trivially related to each other in LCDM, but...

Yes, this is eventually gonna bite us in the ass. We have a relatively nice formalism to store these things (the generalized Pks), but we're not using it for it.