This repository was archived by the owner on Oct 24, 2024. It is now read-only.
This repository was archived by the owner on Oct 24, 2024. It is now read-only.
Consistency between DataTree methods and pathlib.PurePath methods #283
Closed
Description
@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 toDataTree.glob
- Add a new method
DataTree.match
that returns a boolean likePurePath.match
does -
DataTree.lineage
should be renamed to.parents
-
Add an(this is deprecated in.is_relative_to
methodpathlib
) - A new
.joinpath
method could be useful -
DataTree.relative_to
should possibly have awalk_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 sectionPath-like methods