.root incompatible with pathlib

[barneygale]

In pathlib, path.root gives you the path root, i.e. the middle element from os.path.splitroot(). This is either the empty string, a forward slash, a backward slash (Windows only), or two forward slashes (Posix only).

In zipp, path.root points to the archive via a name cache. Perhaps it could be renamed to something that doesn't conflict?

[jaraco]

Good question.

It could be renamed, and probably should be renamed if the meaning of pathlib.Path.root holds for a (zipp|zipfile).Path. I don't think it does, however, suggesting that perhaps the divergent meanings of root across these two classes is appropriate. In other words, perhaps root should not be considered one of the attributes supported for compatibility.

And in another sense, .root is compatible across both implementations by representing the root-most part of the path object.

How is it that it conflicts? Is there a case for why zipfile.Path.root should return something similar to what pathlib.Path.root does?

[barneygale]

The meaning of root does hold for zip files, but the value can only ever be the empty string, if I'm understanding the zip format correctly. Similarly zipp.Path.drive should always be empty in zip files.

(This is different to tarballs, which can store paths with drives and roots)

How is it that it conflicts? Is there a case for why zipfile.Path.root should return something similar to what pathlib.Path.root does?

They give completely different information. In pathlib, root is a lexical component of the path - the middle part of the (drive, root, rel) representation that's fundamental to how pathlib models paths. In zipp.Path it's not even a string, and it instead refers to the backing datastore of the path! It's only compatible in a loose sense.

IMO zipfile would be a better name for the attribute!