I am split here. The change is simple. However, the solution is a bit in between parsing the warning message and just having a nice attribute.

Since the other solution involves adding a __new__ that is scary, the current solution might be enough. We should only document it in the pickling section to provide a code snippet that just works to get the pickling version.

I like it. Same question as Adrin about the parsing vs separate arguments.

A curiosity: when I load an estimator pickled in an older version of sklearn in ipython I see the same warning twice. Does someone know if this is a "weird thing" related to ipython or normal behaviour or something totally different?

A separate thing (so we can punt it to a new PR if we want to) that I find confusing about this is that a estimator pickled with v1 and then unpickled with this PR (or any future version) will return {..., "_sklearn_version": '1.3.dev0'}. This was also mentioned in the original issue (#22055). It seems weird and easy to fix. It happens because __getstate__ unconditionally adds _sklearn_version to the state dict (return dict(state.items(), _sklearn_version=__version__)), instead I think it should check if the key is present and only set it if it isn't present.

instead I think it should check if the key is present and only set it if it isn't present.

@betatim the key is never present (and I think it's a good thing) since __setstate__ pops it before setting the attributes. If the user saves a model which was loaded from an older sklearn version, we probably don't care about the usecase, do we? I'm happy with this solution.

Shall we document the way to programmatically recover the pickle version in the persistence documentation?

Shall we document the way to programmatically recover the pickle version in the persistence documentation?

Sounds like a good idea. If there is a documented way to get the version used to fit an estimator that reduces the number of people calling __getstate__ to find out.

I hadn't realised that __setstate__ pops the variable, and I did quickly read the code ... . Combined with the fact that it doesn't contain what people are looking for when they poke around, having a documented way of getting the right answer is good.