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
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4