[Python-ideas] os.path.isparent and os.path.ischild

[Paul Moore]

On 8 July 2011 00:08, Giampaolo Rodolà <g.rodola at gmail.com> wrote:
>>>> isparent('/a', '/a/b')
> True
>>>> isparent('/a/b', '/a')
> False
>
>>>> ischild('/a/b', '/a')
> True
>>>> ischild('/a', '/a/b')
> False
>
> Thoughts?

Underspecified.

Are these simply string operations? If not, how would symlinks be
handled? What about case sensitivity (given that detecting case
sensitivity per filesystem is not possible, in practical terms)? What
about os.sep and os.altsep (\ and / on Windows)?

By the time you've answered all of these questions, you may as well
code the operations. Then let's see if people use them before putting
them into the standard library.

If you're only looking at small utility wrappers round
os.path.commonprefix, then I don't see the point (such a wrapper is
easy enough to write if you need it in your own code).

In reality, os.path is a compromise providing "simplistic but good
enough" path handling. If I assume you intend these operations also to
be "simplistic but good enough", then I see little benefit that I
can't get with os.path.commonprefix (and maybe a couple of lines of
wrapper, if I use the idiom a lot).

Personally, I don't expect I'd ever use something like this.

Also, if isparent(x,y) and ischild(y,x) are intended to be equivalent,
then I don't see the value in having both (comments about comparison
operators notwithstanding). And if there's a subtle difference I've
missed, you haven't explained it well enough :-)

Having said all this, I support the idea of having a better set of
path handling functions in the stdlib. But it's far from a simple
problem to do it right in a sufficiently cross-platform way. And just
adding functions to os.path probably isn't the right way to start.

Paul.