`lock` kwarg needs a deprecation cycle?

[fmaussion]

Salem's tests on master fail because I use the lock kwarg to open_dataset, which seems to have disappeared in the backend refactoring.

Should the new open_dataset simply ignore lock, and raise a FutureWarning when used?

[max-sixty]

Yes that sounds right, thanks for spotting @fmaussion . (I am hazy on the differences but I think it's a DeprecationWarning since we're removing it rather than changing its behavior)

[fmaussion]

I think it's a DeprecationWarning since we're removing it rather than changing its behavior

Ha! I'm no expert either. I learned one thing recently though: DeprecationWarnings are silenced by python per default when not raised directly from __main__ and are therefore invisible for many users.

https://stackoverflow.com/questions/66590950/deprecationwarning-is-not-raised-on-import

https://stackoverflow.com/questions/55377831/difference-between-deprecationwarning-pendingdeprecationwarning-and-futurewarni

[keewis]

as far as I understand the docs of DeprecationWarning and FutureWarning, the main difference is the intended target audience in a traditional library vs. application setting (where libraries are always used to write applications): PendingDeprecationWarning and DeprecationWarning are used to signal deprecations in the library, while FutureWarning are intended for users of the application. Interestingly, PEP565 mentions that FutureWarning can also be used for changed semantics of valid code.

If we follow that, xarray should not issue FutureWarning (other than to report changing semantics) because it is a library and both interactive and scripted use would be similar to writing a application.

[dcherian]

We should fix this before the next release.

[alexamici]

Sorry for being so late to the party! I thought @aurghs did respond to this issue and forgot about it.

What has happened is not that lock (and group for the matter) disappeared altogether, but it has been moved to be a backend specific keyword argument. As far as I can see most internal backends still support it as before: cfgrib, netcdf4, pseudonetcdf, pynio and scipy.

The main difference is that lock was silently ignored by backend that don't support it like zarr and pydap.

The solution is to in fact only advertise the deprecation for those backends in my opinion as the functionality is legit for most of the backends.

Sorry again for seeing this so late.

[TomNicholas]

No worries @alexamici ! I've merged your PR and it automatically closed this one.