~20% globbing speedup:

$ ./python -m timeit -s'from pathlib import Path; p = Path()''list(p.glob("**/*", follow_symlinks=False))'2 loops, best of 5: 175 msec per loop# before2 loops, best of 5: 146 msec per loop# after

I've moved this to a newglob.translate() function.

It was easy enough to implement arecursive argument, so I did that and made its defaultFalse to matchglob().

It's much harder to implement aninclude_hidden argument, so I've left that for now. I don't feel great about it, tbh.

Right, after some futzing around I'm going to mark this PR as ready again.

Infnmatch.py, I've split thetranslate() method into_translate() and_join_translated_parts(). This minimises the diff, risk, and performance impact in that module.

(In#109879 I've re-implementedfnmatch.translate(), but that PR is an optional side-quest now)

Inglob.py, I've spent some time making the implementation oftranslate(include_hidden=False) as clear and performant as I can. There's still a fair whack of regex involved but Ithink it's followable.

Inpathlib.py, I've made pattern matching usestr(path) directly, rather than a slight variant that represents empty paths as'' rather than'.'.

Timings:

$ ./python -m timeit -n 5 -s 'from glob import glob' 'list(glob("**/*", recursive=True, include_hidden=True))'5 loops, best of 5: 105 msec per loop  # for interest$ ./python -m timeit -n 5 -s 'from pathlib import Path; p = Path()' 'list(p.glob("**/*", follow_symlinks=True))'5 loops, best of 5: 86.6 msec per loop  # before5 loops, best of 5: 72.7 msec per loop  # after

SoPath.glob() is ~20% faster than before, and ~45% faster thanglob.glob(), at least for this test case.

I've realised that the docs are a bit skew-whiff. Fix is in a separate PR:#110418

Is it correct to keep duplicated path separators?

>>>glob.translate('a//b')'(?s:a//b)\\Z'

Is it correct to keep duplicated path separators?

>>>glob.translate('a//b')'(?s:a//b)\\Z'

glob() keeps them:

>>>os.makedirs('a/b')>>>glob.glob('a//b')['a//b']

So I reckon yes?

Also, the number of additional slashes is meaningful in some cases, e.g. in Windows UNC paths or POSIX paths starting with two forward slashes. I don't think a pattern like/foo should match a path like//foo, and vice-versa.

Hey@encukou, do you think I can merge this, or should I wait for a more complete review from someone?

Oh, I should have been more clear that I wouldn't get to a thorough review in any reasonable time.
You already have a few approvals, merge away!