Home Original page

[Python-Dev] Pathlib enhancments - method name only

Nick Coghlan ncoghlan at gmail.com
Sun Apr 10 01:04:47 EDT 2016 
On 9 April 2016 at 23:02, R. David Murray <rdmurray at bitdance.com> wrote:
> That is, a 'filename' is the identifier we've assigned to this thing
> pointed to by an inode in linux, but an os path is a text representation
> of the path from the root filename to a specified filename.  That is,
> the path *is* the name, so to say "path name" sounds redundant and
> confusing to me.

"The path is the name" is a true statement in the context of:

1. The way *nix APIs work
2. Existing filesystem interfaces in the standard library
3. Path abstractions that inherit from str/unicode

It's no longer true in the context of pathlib - there, the path name
is a serialised representation of a rich path object.

It's also not really true in the context of Python 3 in general -
bytes-like objects are an encoding of the path name, rather than the
name itself.

This means that "path" has become ambiguous due to the changing
context - do we mean the path name representation, the binary encoding
of that name, or a higher level rich path object?

We're never going to be able to eliminate that ambiguity (Python's
*nix & C roots run too deep for that), but we *can* potentially
standardise the terms used when disambiguation is needed: path name
(str), encoded path name (bytes-like object), rich path object (object
implementing the new protocol)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
More information about the Python-Dev mailing list