path is a string that happens to know about the filesystem

Why subclass str rather than wrap it

The central design choice is that a path object is a subclass of str, and the README explains what that buys. These Path objects may be passed directly to other APIs that expect simple text representations of paths, whereas with pathlib one must first cast values to strings before passing them to APIs that do not honour the PEP 519 PathLike interface. That is the whole argument, and it is an argument about legacy code rather than about elegance. Any function in your codebase that does something like open(name) or subprocess.run([..., name]) keeps working when name is a path object, because a path object is a string with extra methods attached. The trade is the usual one for inheriting from str, that the type is also a string in every isinstance check that matters, and the project has accepted that trade in exchange for compatibility. The package itself is called path, the import is from path import Path, and it was formerly called path.py, with the current release still on the 17.x line.

The conveniences pathlib does not give you

The second advantage the README claims is quality of life features beyond exposing the basic functionality of a path. The methods include rmtree, taken from shlib, and remove_p, which removes a file if it exists. There are properties like .permissions, and the README calls out sophisticated walk, TempDir and chmod behaviours. The walk and chmod entries are the interesting ones, because a chmod that takes a symbolic mode string rather than only a numeric one is the sort of small ergonomic decision that turns a scripting session into a sequence of conversions, and TempDir is a scoped temporary directory that cleans up after itself. The features are all in the same register, they are the operations you write in a cleanup script rather than in an application, which is consistent with the testimonial in the README, where a Python 101 article on writing a cleanup script is based on path. The one caveat is that these are additions rather than replacements, since the basic operations still behave as the os.path module does.

The Path.module indirection is the subclassing story

The third advantage is portability through a uniform abstraction over a single Path object, which frees the implementer to subclass it readily, and the README is explicit about the pathlib comparison here. One cannot subclass a pathlib.Path to add functionality, but must subclass Path, PosixPath and WindowsPath, even to do something as simple as adding a __dict__ to the subclass instances. path instead allows the Path.module object to be overridden by subclasses, defaulting to the os.path module. So a subclass can point its path operations at a different backend without touching every call site, and even advanced uses of path.Path that subclass the model do not need to be concerned with OS-specific nuances. The consequence the README draws is that path.Path objects are inherently pure, not requiring the author to distinguish between pure and non-pure variants. That is a real advantage for a library that wants to offer a portable API, and it is also the design that makes pathlib's PosixPath and WindowsPath split a thing you would design differently if you were starting over.

The everyday API, in a dozen lines

The usage examples in the README are short, which is the point, since the object is a string. You construct one from a path, iterate over the matching files, and call methods on them directly:

from path import Path

d = Path("/home/guido/bin")
for f in d.files("*.py"):
    f.chmod(0o755)

The same loop appears twice in the README, once with a numeric mode and once with a symbolic one, which shows that chmod accepts both:

for f in d.files("*.py"):
    f.chmod("u+rwx")

The object also works as a context manager for changing the working directory, with the comment that the cwd is now somewhere, and concatenation with the / operator produces a new path:

with Path("somewhere"):
    # cwd in now `somewhere`
    ...

foo_txt = Path("bar") / "foo.txt"

An explicit aim to be a drop-in for pathlib

The project states that it has the explicit aim to provide compatibility with pathlib objects where possible, such that a path.Path object is a drop-in replacement for pathlib.Path objects, and it welcomes contributions to improve that compatibility where it is lacking. That sentence is the most useful thing in the README for anyone evaluating it, because it tells you the relationship is intentional rather than accidental. It also tells you where the limits are. A drop-in replacement is a goal that is being worked on, not a guarantee, and a user who reaches for a pathlib feature that path does not have will find a gap. The project also states that path is free to iterate faster than a stdlib package, which is the practical argument for a third party implementation of something the standard library also offers, and that contributions are welcome and encouraged. The runtime dependency list in the packaging metadata is empty, so adopting path adds nothing to your dependency graph, which is the strongest practical argument for it.

Twenty years of maintenance, and the current state

The origins are stated plainly. The path.py project was initially released in 2003 by Jason Orendorff, and has been continuously developed and supported by several maintainers over the years, with the packaging metadata naming Orendorff as the author and Jason R. Coombs as the maintainer. The version history is steady, with v17.0.0 on 2024-07-27, v17.1.0 on 2024-12-28 and v17.1.1 on 2025-07-27, and the last push was on 2026-10-17, so the project remains active. The packaging metadata classifies the project as Development Status 5, Production/Stable, requires Python 3.10 or above, and declares an MIT licence. The development tooling is thorough for a package this small, with a Ruff badge and ruff.toml, a mypy.ini, a pytest.ini, a tox.ini, a towncrier.toml for the change log, a NEWS.rst, a SECURITY.md, and a set of optional test extras that plug pytest into the checks, among them pytest-checkdocs, pytest-ruff, pytest-cov, pytest-mypy and pytest-enabler. The docs extras pull in sphinx and a small set of jaraco packages, and the package is also available through the Tidelift subscription for enterprise users.

When pathlib is the better answer

The honest comparison is against the standard library, and for new code pathlib usually wins. It ships with Python, it is documented in the language reference, it is typed, and it has a design that was reviewed by the people who maintain CPython rather than by one project. The argument for path is about context. If you are writing new code with no legacy string handling, a str subclass buys you little and costs a dependency, and the extra methods, while pleasant, are a handful of lines you could write yourself or borrow from a small utility module. The other case is a codebase that predates pathlib and passes paths as strings everywhere, where changing to pathlib means touching every call site and every third party function that expects a string, and there path is a much cheaper migration. That is a real and common situation, and it is the situation the str subclass exists to solve, which is why the project describes itself as a module wrapper for os.path rather than as a pathlib replacement.

Editorial conclusion

path is worth reaching for when you have existing code that treats paths as strings, because a str subclass drops into it without casts, and when you want the handful of conveniences that pathlib deliberately does not provide, such as a remove_p that tolerates a missing file and a directory context manager. It is the wrong dependency for new work that has no legacy string handling, because pathlib is in the standard library, better documented and typed, and adding a third party package for it needs a reason. Before adopting it, check the compatibility promise yourself, since the project states an explicit aim to be a drop-in replacement for pathlib objects where possible rather than a guarantee, and note that the newest listed release is v17.1.1 from 2025-07-27, so check the release list before depending on a specific version.

Frequently asked questions

Official sources

1. Issues
2. jaraco/path on GitHub
3. README
4. Releases