
Well, "path" is much too common already, and it's an obvious variable name for a filesystem path, so "pathlib" is better to avoid name clashes.
Yep, that makes total sense, thanks.
However, it seems there was no further discussion about why not "extension" and "extensions"? I have never heard a filename extension being called a "suffix". I know it is a suffix in the sense of the English word, but I've never heard it called that in this context, and I think context is important. Put another way, "extension" is obvious and guessable, "suffix" isn't.
Well, perhaps :-), but nobody opposed suffix and suffixes at the time. Note the API is provisional, so we can still make it change, but obviously the barrier for changes is higher now that the PEP is accepted and the beta has been cut.
Okay. I won't push hard :-) as "suffix" isn't terrible, but has anyone else never (or rarely) heard the term "suffix" applied to filename extensions?
3) Obviously pathlib isn't going in the stdlib in Python 2.x, but I'm wondering about writing portable code when you want the string version of the path. In Python 3.x you'll call str(path_obj), but in Python 2.x that will fail if the path has unicode chars in it, and you'll need to use unicode(path_obj), which of course doesn't work 3.x.
The behaviour of unicode paths in Python 2 is erratic (system-dependent). pathlib can't really fix it: Python 2 doesn't know about a well-defined filesystem encoding.
Fair enough.
4) Is path_obj.glob() recursive?
This is documented: http://docs.python.org/dev/library/pathlib.html#pathlib.Path.glob http://docs.python.org/dev/library/pathlib.html#pathlib.Path.rglob
Seems much more Pythonic to provide an actual argument (or different function) for this change in behaviour, rather than stuffing the "recursive flag" inside the pattern string.
It's not a flag, it's a different wildcard. This allows e.g. a library function to call glob() and users to pass a recursive or non-recursive pattern as they wish.
Okay, just saw those docs now -- thanks. Fair enough re "it's a different wildcard". At the least I don't think there should be two ways to do it -- in other words, either rglob() or glob('**'), both seems very un-PEP 20 to me. My preference is rglob(), but glob(recursive=True) would be fine too.
Has this ship already sailed with http://bugs.python.org/issue13968?
This issue is still open, so no :-)
Same goes for this issue -- there should be OOWTDI, and my preference is rglob() or glob(recursive=True). But maybe issue 13968's behaviour can be determined by pathlib's now that pathlib is the one getting done first. Thanks, Ben.