~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  # before
2 loops, best of 5: 146 msec per loop  # after

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

It was easy enough to implement a recursive argument, so I did that and made its default False to match glob().

It's much harder to implement an include_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.

In fnmatch.py, I've split the translate() method into _translate() and _join_translated_parts(). This minimises the diff, risk, and performance impact in that module.

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

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

In pathlib.py, I've made pattern matching use str(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  # before
5 loops, best of 5: 72.7 msec per loop  # after

So Path.glob() is ~20% faster than before, and ~45% faster than glob.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!