I was thinking today that it would be natural for paths to support __contains__ since then you could write statements like `if file in dir` or `if subdir in dir` cleanly. The library plumbum appears to already have this, but I think it could be useful in the standard library: https://plumbum.readthedocs.io/en/latest/_modules/plumbum/path/base.html#Path.__contains__
I can make these changes. Would probably add a .exists method to PurePath, using the _normal_accessor.stats staticmethod, then call that in __contains__
Not a good idea IMHO. Why would containment mean the existence of a file in a directory? It could just as well mean that a certain path component is part of the path. Also I don't understand what would e.g. `Path('/usr/bar') in Path('/etc/foo')` mean. As for adding a .exists method to PurePath, I think you're missing the point of PurePath here (i.e. its operations *don't* do any IO whatsoever).
I think the idea is that either a subdir or file could be valid inputs. So `Path('/usr/bar') in Path('/etc/foo')` return True if `Path('/etc/foo/usr/bar')` is either a dir or file. As for PurePath, I did overlook that accessing an inode via a call to stat would be considered filesystem IO. So putting that method in Path (if this turns out to be a good idea) is the better option. Thanks
There was a similar (closed) issue about making Path an iterable. The problem with both these related ideas is that they are ambiguous. Does it means that a directory contains a specified file, or that a path contains a specified path component, or that a specified path is a prefix of other path? There are third-party pathlib-like implementations that make Path a str subclass. They have both __iter__ and __contains__ inherited from str, but with different meaning. I'm -1. It is better to write explicitly what you mean than allow the computer to guess.
History
Date
User
Action
Args
2022-04-11 14:58:59
admin
set
github: 77482
2019-01-14 10:05:28
serhiy.storchaka
set
status: open -> closedresolution: rejectedstage: resolved
