| msg285297 - (view) |
Author: Jon Walsh (Jon Walsh) |
Date: 2017-01-12 10:19 |
| >>> from pathlib import Path >>> Path("a/b/c/d/e.txt").match('a/*/**/*') False |
|
|
| msg285305 - (view) |
Author: Andrew Dunai (Andrew Dunai) |
Date: 2017-01-12 11:11 |
| Isn't this intended? According to https://docs.python.org/2/library/glob.html and wiki, typical UNIX glob pattern does not have the reqursive matching operator (`**`). |
|
|
| msg285308 - (view) |
Author: Christian Heimes (christian.heimes) *  |
Date: 2017-01-12 11:20 |
| The ticket is not about glob but about pathlib. Pathlib supports ** directory globbing, but it's only documented as prefix globbing, https://docs.python.org/3/library/pathlib.html#pathlib.Path.glob |
|
|
| msg285311 - (view) |
Author: Serhiy Storchaka (serhiy.storchaka) * |
Date: 2017-01-12 11:32 |
| ** is supported not just as a prefix. Path('./Lib').glob('**/*.py') emits the same paths as Path('.').glob('Lib/**/*.py'). But ** is supported only in glob(), not in match(). The support of ** in match() is not documented. Would be worth to document explicitly that it is not supported. |
|
|
| msg285323 - (view) |
Author: Jon Walsh (Jon Walsh) |
Date: 2017-01-12 13:23 |
| Seems a bit strange to not have glob() and match() working the same though. Is there any reason for that? |
|
|
| msg307854 - (view) |
Author: Dustin Spicuzza (virtuald) * |
Date: 2017-12-08 16:52 |
| I just ran into this also. It seems like a very strange omission that match and glob don't support the same patterns (and I'm surprised that they don't share more code). |
|
|
| msg307866 - (view) |
Author: Dustin Spicuzza (virtuald) * |
Date: 2017-12-08 19:40 |
| Because of backwards compatibility (despite a statement saying it's not guaranteed for pathlib), I think the best approach would be to create a 'globmatch' function for PurePath instead of modifying the match function, and document that the match function does a different kind of matching. This isn't a patch for cpython per se (ironically, don't have time for that this month...), but here's a MIT-licensed gist that patches pathlib2 and adds a globmatch function to it, plus associated tests extracted from pathlib2 and my own ** related tests. Works for me, feel free to do with it as you wish. https://gist.github.com/virtuald/dd0373bf3f26ec0730adf1da0fb929bb |
|
|
| msg325735 - (view) |
Author: Ronny Pfannschmidt (Ronny.Pfannschmidt) |
Date: 2018-09-19 08:15 |
| was a duplicate of this pytest was affected, as we port more bits to pathlib we hit this as well bruno kindly implemented a local workaround in https://github.com/pytest-dev/pytest/pull/3980/files#diff-63fc5ed688925b327a5af20405bf4b09R19 |
|
|
| msg361147 - (view) |
Author: Isaac Muse (Isaac Muse) |
Date: 2020-02-01 01:39 |
| I think the idea of adding a globmatch function is a decent idea. That is what I did in a library I wrote to get more out of glob than what Python offered out of the box: https://facelessuser.github.io/wcmatch/pathlib/#purepathglobmatch. Specifically the differences are globmatch is just a pure match of a path, it doesn't do the implied `**` at the beginning of a pattern like match does. While it doesn't enable `**` by default, such features are controlled by flags >>> pathlib.Path("a/b/c/d/e.txt").match('a/*/**/*', flags=pathlib.GLOBSTAR) True This isn't to promote my library, but more to say, as a user, I found such functionality worth adding. I think it would be generally nice to have such functionality in some form in Python by default. Maybe something called `globmatch` that offers that could be worthwhile. |
|
|
| msg382535 - (view) |
Author: Miroslav Šedivý (eumiro) * |
Date: 2020-12-04 21:54 |
| Today when porting some random project from os.path to pathlib I encountered a homemade filename matching method that I wanted to port to pathlib.Path.match. Unfortunately >>> pathlib.Path('x').match('**/x') False although if I have a file called `x` in the current directory, both >>> pathlib.Path('.').glob('**/x') and zsh's $ ls **/x can find it. It would be really nice to have analogous .glob and .match methods. |
|
|
| msg386795 - (view) |
Author: Julien Palard (mdk) * |
Date: 2021-02-10 17:30 |
| I'm +1 on adding ** to match. My first bet would be to add it to match, not adding a new method, nor a flag, as it should not break compatibility: It would only break iif someone have a `**` in a match AND does *not* expect it to be recursive (as it would continue to match the previous files, it may just match more). Would this break something I did not foresee? |
|
|