PEP 639, Round 3: Improving license clarity with better package metadata

Given that not all clients may be written in Python, I’d suggest simply specifying exactly what’s supported. The explanation of supported patterns in the glob docs takes a bit of reading to understand (what is a “hidden” file? are initial dots treated specially on Windows as well as Unix? is the spec assuming “recursive” is set so that ** is supported?)

I’d be fine with a spec that said consumers must support at least *, [...] (without [!...]) and **, and for portability users should restrict themselves to those patterns and alphanumeric filenames (plus a dot for extensions). That covers any realistic use cases without requiring a custom implementation from tools.

8 Likes