UPath("/", protocol="memory").is_absolute() == False

[cscutcher]

I can kinda see why this is happening in the code, but can't tell if it's intentional.

Naively, I'd expect UPath("/", protocol="memory") to be an absolute path. Especially since UPath("/foo", protocol="memory") is an absolute path, and UPath("/foo", protocol="memory").parent == UPath("/", protocol="memory").

I'd guess this is a bug, but wasn't sure if this was a side-effect of trying to generalise everything consistently, especially with regard to the memory filesystem.

Similarly, UPath(".").name == "" which makes sense to me, but UPath(".", protocol="memory").name == '.' . Was this an intentional decision or is it a bug?

Thanks in advance!

[ap--]

Hi @cscutcher

Thanks for reporting!

UPath('/', protocol="memory")

Should indeed be absolute, since all memory paths are absolute. It's an edge-case that we're missing from the test cases. Would you want to add a test case to upath/tests/cases.py? A cross filesystem way of testing this is to ensure that in the test path all .parents are absolute.

The other case is a bit more complicated: UPath(".", protocol="memory").name == '.' for memory filesystems . is actually a valid filename, i.e. you can store data under ..
It's worth considering though if, for the sake of aligning with local path pathlib behaviour this should maybe require explicit opt-in. I'll think about it.

[cscutcher]

Thanks for looking at this and sorry for the slow reply! I see that you've already got a fix and test. Thanks for looking at this so quickly!

For me the big selling point of the library is accepting UPaths but being completely agnostic about what backend is in use. It's probably not possible to be 100% agnostic, but I think a good starting place would be if there were at least clear definitions documented for the meaning of UPath(""), UPath("/"), UPath(".") and UPath("..") .

In all four cases, before I started thinking about it in the context of UPath, I would have naively said I had a clear understanding of what those paths mean. However, once I started thinking about specifics, especially in the case of UPath's filesystem agnostic approach, I realised I was a bit clueless!

For context, in case it's helpful in your design considerations, I was using the memory backend primarily for testing, so in my case I really wanted behaviour to be as similar as possible to the local filesystem. In the end I awkwardly subclassed MemoryFileSystem and MemoryPath so I work around this issue, but also to implement symlink support which I believe is missing in MemoryFileSystem. I imagine it's possible that my choice of using MemoryFileSystem as a mock local filesystem, goes against the original intent for it, so maybe I was doomed from the start!

Another small comment, but how to handle relative paths in general seems an interesting challenge. I'm sure there are good reasons why this isn't the case, but it seems to me that relative paths shouldn't necessarily be tied to any protocol or backend. I can see why making UPath("foo/bar") implicitly a path relative to cwd on the local file system, would be necessary to make .open etc work as a user might expect, but it would be nice to be able to have an explicitly relative path.
To me, in a backend agnostic world, a path like foo/bar should only get tied to a specific backend when it's combined with some absolute path object, but on it's own it only states "the subdirectory bar, which is the subdirectory of foo" which should be possible to apply to any filesystem backend equally, if that makes sense.

[ap--]

Thanks for the feedback! I created a new issue for discussion: #498