@eschalkargans suggested in #281 that the API of DataTree objects could more closely follow that of pathlib.PurePath objects. I think this aligning of APIs/nomenclature is a good idea. In general think it's conceptually useful to think of a DataTree object as if it were an instance of pathlib.PurePosixPath (even though the actual implementation should not work like that).

There are various methods we might want to add/change to make them more compatible:

Inspired by pathlib.PurePath:

• DataTree.match should be renamed to DataTree.glob
• Add a new method DataTree.match that returns a boolean like PurePath.match does
• DataTree.lineage should be renamed to .parents
• Add an .is_relative_to method (this is deprecated in pathlib)
• A new .joinpath method could be useful
• DataTree.relative_to should possibly have a walk_up method (see Use new walk_up parameter in pathlib for traversing relative paths #258)
• A new .with_name method might be useful
• A new .with_segments method might be useful

Inspired by pathlib.Path (i.e. concrete paths):

• A new DataTree.walk method might be a better way to expose the logic in iterators.py
• A new .rename method might be useful
• A new .replace method might be useful
• A new .rglob method (though having this and .glob seems overkill)

Several of these might be useful abstractions internally, especially .joinpath, .walk, and .replace.

EDIT: Let's also document this similarity:

• Add section to documentation explicitly pointing out this alignment of APIs (Add Pathlike methods to api docs #287)
• Reorganise api.rst to have a section Path-like methods