Fix deepcopy of user data

[mgunyho]

Description

I was making use of the user_data attribute of a Parameter, and noticed that it is not deep-copied when using the copy() method of Parameters. Here is a simple example:

import lmfit

def func(x, a):
    return a * x

model = lmfit.Model(func)

params = model.make_params()
params.get("a").user_data = {"foo": 123 }

params2 = params.copy()
params2.get("a").user_data["foo"] = 456

print(params.get("a").user_data) # prints {'foo': 456}

This PR fixes this behavior.

Type of Changes

• Bug fix
• New feature
• Refactoring / maintenance
• Documentation / examples

Tested on

Python: 3.10.9 (main, Dec 08 2022, 14:49:06) [GCC]

lmfit: 1.1.0.post1+g1a3b1009, scipy: 1.10.0, numpy: 1.24.1, asteval: 0.9.28, uncertainties: 3.1.7

Verification

Have you

• included docstrings that follow PEP 257? - N/A

• referenced existing Issue and/or provided relevant link to mailing list? - N/A

• verified that existing tests pass locally?

• verified that the documentation builds locally? - N/A, no changes to docs

• squashed/minimized your commits and written descriptive commit messages? - let me know if you want me to squash them into one commit

• added or updated existing tests to cover the changes?
• updated the documentation and/or added an entry to the release notes (doc/whatsnew.rst)?
• added an example? - N/A

[reneeotten]

what's the purpose of this change - why would one want to make things fail when user_data is a dictionary? Or am I missing something here?

[mgunyho]

With this change, the test covers a case that was not covered before, where the user data is a mutable object such as a dict or list. See the example code in the PR: modifying the user data of the copied params2 modifies the user data of the original params.

[reneeotten]

I see what you mean. In the current test "user_data" was an int/float value in both cases, replacing one with a more complicated type makes sense!

[reneeotten]

I don't have a real issue with doing this, but why is it explicitly needed here and not for any of the other attributes - that doesn't make complete sense to me, but admittedly I haven't looked carefully yet...

[mgunyho]

I am quite new to lmfit, so I'm not sure which of the other attributes are mutable types, maybe correl is for example. I agree that it looks a bit asymmetric, but this at least fixes this bug.

[newville]

@mgunyho @reneeotten Thanks - I do agree that user_data is the most likely to be mutable. I think we should do a deepcopy on user_data and correl and probably everything in the user_defined_symbols, as with

unique_symbols = {key: deepcopy(self._asteval.symtable[key]) for key in self._asteval.user_defined_symbols()}

[mgunyho]

That seems reasonable. I am not familiar with the internals of Parameter, and I'm not sure if/how the tests should be updated to check that the behavior wrt _asteval or the other attributes is correct. You should be able to add commits to this PR, so feel free to do so if you don't want to make a separate one.

[newville]

@mgunyho @reneeotten will merge and update #844