On 9 April 2016 at 23:02, R. David Murray <[email protected]> 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 | [email protected] | Brisbane, Australia _______________________________________________ Python-Dev mailing list [email protected] https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com