[Python-Dev] PEP 428 - pathlib API questions

Antoine Pitrou solipsis at pitrou.net
Sun Nov 24 23:29:21 CET 2013


Hello,

On Mon, 25 Nov 2013 11:00:09 +1300
Ben Hoyt <benhoyt at gmail.com> wrote:
> 
> 1) Someone on reddit.com/r/Python asked "Is the import going to be
> 'pathlib'? I thought the renaming going on of std lib things with the
> transition to Python 3 sought to remove the spurious usage of
> appending 'lib' to libs?" I wondered about this too. Has this been
> discussed/answered?

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.

> 2) I think the operation of "suffix" and "suffixes" is good, but not
> so much the name. I saw Ben Finney's original suggestion about
> multiple extensions etc
> (https://mail.python.org/pipermail/python-ideas/2012-October/016437.html).
> 
> 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.

> 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.

> 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.

> Has this ship already sailed with http://bugs.python.org/issue13968?

This issue is still open, so no :-)

Regards

Antoine.




More information about the Python-Dev mailing list