It recently occurred to me that it's a little odd how we never got better Path types for Python.
Pathlib was a significant upgrade over plain strings back in 3.4, but a decade on we're still
treating all paths as interchangeable. We can now distinguish str vs. Literal vs. LiteralString
— why not paths that must exist from paths that must not? Files from directories? Subpaths from roots?
In the interests of having this be more than a throwaway thought, I wrote up my ideas here in a little more detail.
From thinking about that (in parts 1 and 2), other points of interest sprung to mind.
As well as types indicating what a path represents (beyond merely housing OOP path operations) I never found it particularly elegant to express things like path connectivity, even though it's their core property: if I want to specify a path as a subpath of another, I can't 'variable-ise' that relation. I got into this in part 3.
By this point I had come up with a proof-of-concept toy demo, whose flaws were already visible. In part 4 I discuss how this is a term-rewriting-shaped problem, in the realm of compilersa. I distinguish a path with deferred symbol resolution (but immediate binding) from a genuinely late-binding deferred (lazy execution) implementation.
In part 5 I focus on the best ideas from part 4 to re-do the t-string based Path implementation with genuine laziness (deferring the Path construction not just constructing a symbolic path), bringing Rust in under the hood.