-
-
Notifications
You must be signed in to change notification settings - Fork 31.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
GH-73435: Add pathlib.PurePath.full_match()
#114350
Conversation
In 49f90ba we added support for the recursive wildcard `**` in `pathlib.PurePath.match()`. This should allow arbitrary prefix and suffix matching, like `p.match('foo/**')` or `p.match('**/foo')`, but there's a problem: for relative patterns only, `match()` implicitly inserts a `**` token on the left hand side, causing all patterns to match from the right. As a result, it's impossible to match relative patterns from the left: `PurePath('foo/bar').match('bar/**')` is true! This commit reverts the changes to `match()`, and instead adds a new `globmatch()` method that: - Supports the recursive wildcard `**` - Matches the *entire* path when given a relative pattern As a result, `globmatch()`'s pattern language exactly matches that of `glob()`.
Does the problem extend beyond " Presumably |
|
e.g. zsh man page:
|
Okay, I definitely like having |
pathlib.PurePath.globmatch()
pathlib.PurePath.full_match()
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
Thanks for the reviews, both. |
In 49f90ba we added support for the recursive wildcard `**` in `pathlib.PurePath.match()`. This should allow arbitrary prefix and suffix matching, like `p.match('foo/**')` or `p.match('**/foo')`, but there's a problem: for relative patterns only, `match()` implicitly inserts a `**` token on the left hand side, causing all patterns to match from the right. As a result, it's impossible to match relative patterns from the left: `PurePath('foo/bar').match('bar/**')` is true! This commit reverts the changes to `match()`, and instead adds a new `full_match()` method that: - Allows empty patterns - Supports the recursive wildcard `**` - Matches the *entire* path when given a relative pattern
In 49f90ba we added support for the recursive wildcard `**` in `pathlib.PurePath.match()`. This should allow arbitrary prefix and suffix matching, like `p.match('foo/**')` or `p.match('**/foo')`, but there's a problem: for relative patterns only, `match()` implicitly inserts a `**` token on the left hand side, causing all patterns to match from the right. As a result, it's impossible to match relative patterns from the left: `PurePath('foo/bar').match('bar/**')` is true! This commit reverts the changes to `match()`, and instead adds a new `full_match()` method that: - Allows empty patterns - Supports the recursive wildcard `**` - Matches the *entire* path when given a relative pattern
In #101398 we added support for the recursive wildcard
**
inpathlib.PurePath.match()
. This should allow arbitrary prefix and suffix matching, likep.match('foo/**')
orp.match('**/foo')
, but there's a problem: for relative patterns only,match()
implicitly inserts a**
token on the left hand side, causing all patterns to match from the right. As a result, it's impossible to match relative patterns from the left:PurePath('foo/bar').match('bar/**')
is true!This PR reverts the changes to
match()
, and instead adds a newfull_match()
method that:**
📚 Documentation preview 📚: https://cpython-previews--114350.org.readthedocs.build/en/114350/library/pathlib.html#pathlib.PurePath.globmatch