> > > Another question: What is the real purpose of pure paths? One thing I
> > > see is using them to, say, manipulate Windows paths on a Posix machine
> > > for some reason.
> >
> > Yes. Also, if some reason you want to be sure you're only doing path
> > computations, not I/O.
> >
> 
> "Sure" in what sense, like accidentally? IIUC path
> manipulation/computation operations don't really call into the OS -
> only some methods do.

Yes, I was including the methods inside "computations".

> I mean, having Path, WindowsPath and PosixPath without the pure
> counterparts. You usually use Path, but say you want to manipulate Windows
> paths on a Linux box. So you instantiate a WindowsPath explicitly and do
> your thing on it. You can't (NotImplementedError) call any methods that
> would call into the OS, and that's it.

That would have been a possibility, but I find having distinct classes
much cleaner than raising NotImplementedError in many places.  It's also
self-documenting about which operations are "pure" and which operations
are not.

> I'm just trying to look at the module from the POV of someone who sees it
> for the first time, wondering "why do I have two kinds of things here, and
> when would I want to use each? could I just use Path 99.9% of the time and
> forget about the other options?". If that's true, we may want to reflect it
> in the documentation explicitly - I believe this will make the module
> easier to understand.

Well, at the beginning of the doc there's: """The main point of entry is
the Path class, which will instantiate a concrete path for the current
platform.""", and the "basic use" section only uses the Path class.