"source" encoding for datasets opened from fsspec objects

[keewis]

When opening files from path-like objects (str, pathlib.Path), the backend machinery (_dataset_from_backend_dataset) sets the "source" encoding. This is useful if we need the original path for additional processing, like writing to a similarly named file, or to extract additional metadata. This would be useful as well when using fsspec to open remote files.

In this PR, I'm extracting the path attribute that most fsspec objects have to set that value. I've considered using isinstance checks instead of the getattr-with-default, but the list of potential classes is too big to be practical (at least 4 classes just within fsspec itself).

If this sounds like a good idea, I'll update the documentation of the "source" encoding to mention this feature.

• Tests added
• User visible changes (including notable bug fixes) are documented in whats-new.rst

[max-sixty]

Without knowing much (I generally ds.reset_encoding()) it does sound like a good idea!

[Illviljan]

Shouldn't _normalize_path or _find_absolute_paths be able to handle this?

[keewis]

the main use case is indeed to extract additional data, which you'd do immediately after open_dataset (after which you could drop the encoding).

Shouldn't _normalize_path or _find_absolute_paths be able to handle this?

As far as I can tell, they only convert path-likes to string (which these objects are not, they are file-like, not path-like). Are you suggesting we should change that?

[dcherian]

I think this is fine, but our long-term goal is to delete encoding so you might consider a different solution to your problem.

[keewis]

my impression of that discussion was that we wanted to either return the encoding in a separate object, or somehow remove the encoding after the first operation (i.e. not carry it around). Either way would be fine with me, since I would still have access to it immediately after opening.