[Python-Dev] Pathlib enhancments - method name only (original) (raw)
Eric Snow ericsnowcurrently at gmail.com
Fri Apr 8 18:28:03 EDT 2016
- Previous message (by thread): [Python-Dev] Pathlib enhancments - method name only
- Next message (by thread): [Python-Dev] Pathlib enhancments - method name only
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow <ericsnowcurrently at gmail.com> wrote:
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon <brett at python.org> wrote:
I personally still like ospath as well. Same here. The strings are essentially an OS-dependent serialization, rather than related to a particular file system.
Hmm. It's important to note the distinction between a standardized representation of a path and the OS-dependent representation. That is essentially the same distinction as provided by Go's "path" vs. "path/fliepath" packages. pathlib provides an abstraction of FS paths, but does it provide a standardized representation? From what I can tell you only ever get some OS-dependent representation.
All this matters because it impacts the value returned from ospath(). Should it return the string representation of the path for the current OS or some standardized representation? I'd expect the former. However, if that is the expectation then something like pathlib.PureWindowsPath will give you the wrong thing if your current OS is linux. pathlib.PureWindowsPath.ospath() would have to fail or first internally convert to pathlib.PurePosixPath?
On the other hand, it seems like the caller should be in charge of deciding the required meaning. That implies that returning a standardized representation or even something like a pathlib.PureGenericPath would be more appropriate.
-eric
- Previous message (by thread): [Python-Dev] Pathlib enhancments - method name only
- Next message (by thread): [Python-Dev] Pathlib enhancments - method name only
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]