It’s not a deal breaker, no, but it’s quite a prob...
# kotlinx-files
o
It’s not a deal breaker, no, but it’s quite a problem for usability. There are other issues with a concept of universally applicable
Path
, e.g. in Windows
C:foo.txt
is a “path to foo.txt in a current directory for drive C:“, and it’s different from
C:\foo.txt
which is an absolute path. It is kinda bizzare to apply these Windows concepts to any other file systems. I’m not saying it breaks it, just pointing out there are issues in FS-independent paths. Also I agree that having a data-only path brings a lot of benefits. Just need to have a nice idea/design here.
r
Thought there are many not-really-well-designed things in Python stdlib, the idea behind pathlib type hierarchy can be a thing to get some inspiration from. It supports both "pure" paths not bound to file system instance and actual paths which can be used to run file operations against. Also it separates UNIX-style and Windows-style paths, still having general Path "interface". So mostly there are six kind of paths there: * `PurePath`: base interface bound neither to filesystem type or filesystem instances; * `PurePosixPath`: POSIX-style path not bound to fs instance; * `PureWindowsPath`: Windows-style path not bound to fs instance; * `Path`: abstract fs type-agnostic class bound to fs instance * `PosixPath`: POSIX-style fs instance-bound path eligiable for fs manipulations * `WindowsPath`: Windows-style fs instance-bound path eligiable for fs manipulations. So all in all, code which only works with pure abstract paths has it's own common delimiter type of abstraction, and code needing actual fs access and fs-specific pth manipulation also has type for it's level of abstraction. Though I really like an idea to further separate "pure" and fs instance-bound paths as entirely different things, as ability to pass delegating fs instance which does logging or adds app-specific ACL which library code doesn't know about sounds useful.
o
r
Yeah, saw that :)