ENH: Return Path in `data_path`?

I saw @hoechenberger’s code here:

sample_dir = mne.datasets.sample.data_path()
raw_path = Path(sample_dir) / 'MEG' / 'sample' / 'sample_audvis_raw.fif'

And thought it was a bit sad that he had to Path(...) the data_path() result.

Since 1.0 is coming out, I think one small breaking change we could make would be to return Path instead of str in data_path.

1. It actually matches the name of the function better
2. It should help people modernize their code a bit with things like ...data_path() / 'subject'
3. op.join still works and returns str

The big problem I see is:

1. This fails:

   >>> Path('.') + '/foo'
   TypeError: unsupported operand type(s) for +: 'PosixPath' and 'str'
   

   The fix is pretty easy in this case, but it will break people’s code. The fix is pretty easy, but it’s still some pain…

We can probably get around this, though, with some class magic – we could subclass PosixPath and WindowsPath with support for a + operator, where if the other arg is a str then we cast to str and return op.join(path_str, other_str) (after stripping op.sep from the other_str).

Thoughts?

An alternative would be to do something like data_path(..., out='path'), but I’m not sure that’s much better than having people import from pathlib (though I guess it’s shorter). One advantage of that approach is that we could deprecate out='str' -> out='path' to give people time to change.

[cbrnr]

I’m in favor of this change. With our usual deprecation cycle, I think it’s OK if people need to update their code. I don’t think you can expect to run an old analysis with the latest MNE-Python – for this use case, people can use older versions of MNE-Python. It’s not worth adding a lot of custom code just to keep the old + behavior around.

[cbrnr]

Yes sure, but why don’t you use the MNE version you used when you created the script? Ideally, you should already have an environment which preserves exact versions. But I know, that’s probably not what the average user does.

Anyhow, this discussion is drifting off a bit, so to come back to the original issue and proposed solution, I think we all agree that @larsoner’s suggestion both uses proper deprecation and in two versions will be gone without any leftovers for us to keep maintaining - so a perfect solution to me!