paths type: support str and bytes

[ThomasWaldmann]

#1 notes:

"... and I am also thinking about making the encode parameter optional to avoid unnecessary encode/decode calls, which would make path arguments and return values Optional[Union[str, bytes]]."

[ThomasWaldmann]

I thought this deserved to be mentioned in an open issue, just so it is not forgotten.

It's not just about efficiency, it is about supporting all paths allowed on POSIX OSes - they are C strings and they allow any bytes except the 0x00 byte, which is used as string terminator. Also / obviously has special semantics as path separator.

This is not about an exotic use case: a lot of "grown old" filesystems have a mix of weird paths, especially on old Samba servers which have gone through a history of clientside and server side encodings, configuration mistakes, etc. - there is all kinds of crappy paths to be seen there!

So we have to expect that paths can't be decoded to unicode (Python str), even if we knew their correct coding (which we usually don't even know), and the best way to deal with it would be to not decode/encode at all.

[ThomasWaldmann]

See also #25.

[mxmlnkn]

It's not just about efficiency, it is about supporting all paths allowed on POSIX OSes

Fully agree.

It would also be nice to get rid of the encode/decode trouble at every second line to make mfusepy even thinner and more maintainable in some major version release. Prior mfusepy major versions could then be used for a quick switch from fusepy, and then by successively upgrading the major version, one could slowly port one's own implementation.

[ThomasWaldmann]

Guess we could have a flag (like for the nanosecond resolution) that switches the api between bytes and str.