Pathlib enhancments - method name only
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does.
I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of the fact that a path is *not a string*, but rather a string is a *representation* (or serialization) of a path.
That's a decent point. So the plausible choices are, I think: - __fspath__ # File System Path -- possible confusion with Path - __fsstr__ # File System String - __fspathstr__ # File System Path String -- zero ambiguity, but # what a mouthful -- ~Ethan~
On Fri, Apr 8, 2016 at 11:13 AM, Ethan Furman <ethan@stoneleaf.us> wrote:
So the plausible choices are, I think:
- __fspath__ # File System Path -- possible confusion with Path
- __fsstr__ # File System String
I think we really need "path" in there somewhere....
- __fspathstr__ # File System Path String -- zero ambiguity, but # what a mouthful
we rejected plain old __path__ because this is already ued in another context, but if we add "str" on the end, that's not longer an issue, so do we need the "fs"? __pathstr__ # pathstring -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Fri, Apr 8, 2016 at 9:20 PM, Chris Barker <chris.barker@noaa.gov> wrote:
we rejected plain old __path__ because this is already ued in another context, but if we add "str" on the end, that's not longer an issue, so do we need the "fs"?
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings. -Koos
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
I'm fine with __pathstring__ , but I thought it was already decided that it would NOT return a bytestring! -CHB -- Christopher Barker, Ph.D. Oceanographer Emergency Response Division NOAA/NOS/OR&R (206) 526-6959 voice 7600 Sand Point Way NE (206) 526-6329 fax Seattle, WA 98115 (206) 526-6317 main reception Chris.Barker@noaa.gov
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
I'm fine with __pathstring__ , but I thought it was already decided that it would NOT return a bytestring!
I sincerely hope that's been settled on. There's no reason to have this ever return anything other than a str. (Famous last words, I know.) ChrisA
On Fri, 8 Apr 2016 at 12:10 Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
I'm fine with __pathstring__ , but I thought it was already decided that it would NOT return a bytestring!
I sincerely hope that's been settled on. There's no reason to have this ever return anything other than a str. (Famous last words, I know.)
It has been settled: pathlib.Path itself won't accept bytes anyway so there's no reason to expect this to ever return anything but str.
On Fri, 08 Apr 2016 19:24:44 -0000, Brett Cannon <brett@python.org> wrote:
On Fri, 8 Apr 2016 at 12:10 Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
But there are other paths than OS file system paths. I prefer __fspath__ or __os_path__ myself. I think the fact that it is a string is implied by the fact that it is getting us the thing we can pass to the os (since Python3 deals with os paths as strings unless you specify otherwise, only converting them back to bytes, on unix, at the last moment). Heh, although I suppose one could make the argument that it should return whatever the native OS wants, and save the low level code from having to do that? Pass the path object all the way down to that "final step" in the C layer? (Just ignore me, I'm sure I'm only making trouble :) --David
On Fri, Apr 8, 2016 at 11:39 PM, R. David Murray <rdmurray@bitdance.com> wrote:
On Fri, 08 Apr 2016 19:24:44 -0000, Brett Cannon <brett@python.org> wrote:
On Fri, 8 Apr 2016 at 12:10 Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
But there are other paths than OS file system paths. I prefer __fspath__ or __os_path__ myself. I think the fact that it is a string is implied by the fact that it is getting us the thing we can pass to the os (since Python3 deals with os paths as strings unless you specify otherwise, only converting them back to bytes, on unix, at the last moment).
Heh, although I suppose one could make the argument that it should return whatever the native OS wants, and save the low level code from having to do that? Pass the path object all the way down to that "final step" in the C layer? (Just ignore me, I'm sure I'm only making trouble :)
My favorites are fspath and pathname, and since this is a dunder methdod, it is not as crucial what it is called. I have the feeling the consensus is converging towards fspath? I'll comment on the bytes issue in the other thread. Boy these threads are all over the place! -Koos
On Fri, Apr 8, 2016 at 9:09 PM, Chris Angelico <rosuav@gmail.com> wrote:
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker <chris.barker@noaa.gov> wrote:
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven <k7hoven@gmail.com> wrote:
__pathstr__ # pathstring
Or perhaps __pathstring__ in case it may be or return byte strings.
I'm fine with __pathstring__ , but I thought it was already decided that it would NOT return a bytestring!
I sincerely hope that's been settled on. There's no reason to have this ever return anything other than a str. (Famous last words, I know.)
ChrisA _______________________________________________ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/g.rodola%40gmail.com
I'm kind of scared about this: scared to state and be 100% sure that bytes won't *never ever* be returned. As such I would call this __fspath__ or something, but I would definitively avoid to use "str". -- Giampaolo - http://grodola.blogspot.com
On Fri, 8 Apr 2016 at 11:13 Ethan Furman <ethan@stoneleaf.us> wrote:
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does.
I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of the fact that a path is *not a string*, but rather a string is a *representation* (or serialization) of a path.
That's a decent point.
So the plausible choices are, I think:
- __fspath__ # File System Path -- possible confusion with Path
+1
- __fsstr__ # File System String
-1 Looks like a cat walked across my keyboard or someone trying to come up with a trendy startup name.
- __fspathstr__ # File System Path String -- zero ambiguity, but # what a mouthful
-1 See above. I personally still like __ospath__ as well.
On Apr 8, 2016, at 3:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon <brett@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.
Huh? I though the strings were a OS-independent, human readable serialization and interchange format. Bytes would be the OS-dependent serialization. But yes, I suppose the file-system-level version would be inodes or something. But this is a string that represents a path, thus __pathstr__. And the term "path" is used all over the place (including os.path and pathlib) for this particular type of path, so I don't see why we need the "fs" or "os", other than the fact that __path__ is already taken. But I'm looking forward to using this bike shed regardless of its color, so that's the last I'll comment on that. -CHB
On Fri, 8 Apr 2016 at 15:21 Chris Barker - NOAA Federal < chris.barker@noaa.gov> wrote:
On Apr 8, 2016, at 3:00 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon <brett@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.
Huh? I though the strings were a OS-independent, human readable serialization and interchange format.
Depends if you use `/` or `\` as your path separator if they are truly OS-independent. :) -Brett
Bytes would be the OS-dependent serialization.
But yes, I suppose the file-system-level version would be inodes or something.
But this is a string that represents a path, thus __pathstr__. And the term "path" is used all over the place (including os.path and pathlib) for this particular type of path, so I don't see why we need the "fs" or "os", other than the fact that __path__ is already taken.
But I'm looking forward to using this bike shed regardless of its color, so that's the last I'll comment on that.
-CHB
Brett Cannon wrote:
Depends if you use `/` or `\` as your path separator
Or whether your pathnames look entirely different, e.g VMS: device:[topdir.subdir.subsubdir]filename.ext;version Pathnames are very much OS-dependent in both syntax *and* semantics. Even the main two in use today (unix and windows) can't be mapped directly onto each other, because windows has drive letters and unix doesn't. -- Greg
On 10 April 2016 at 15:58, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Brett Cannon wrote:
Depends if you use `/` or `\` as your path separator
Or whether your pathnames look entirely different, e.g VMS:
device:[topdir.subdir.subsubdir]filename.ext;version
Pathnames are very much OS-dependent in both syntax *and* semantics.
Even the main two in use today (unix and windows) can't be mapped directly onto each other, because windows has drive letters and unix doesn't.
This does raise a concrete API design question: how should PurePath.__fspath__ behave when called on a mismatched OS? For PurePath vs Path, the latter raises NotImplementedError if you try to create a concrete path that doesn't match the running system:
pathlib.PureWindowsPath(".") PureWindowsPath('.') pathlib.WindowsPath(".") Traceback (most recent call last): File "<stdin>", line 1, in <module> File "/usr/lib64/python3.4/pathlib.py", line 910, in __new__ % (cls.__name__,)) NotImplementedError: cannot instantiate 'WindowsPath' on your system
The question we need to address is what happens if you do:
os.fspath(pathlib.PureWindowsPath("."))
on a *nix system? Similar to my proposal for dealing with DirEntry.path being a bytes-like object, I'd like to suggest raising TypeError in __fspath__ if the request is nonsensical for the currently running system - *nix systems can *manipulate* Windows paths (and vice-versa), but actually trying to *use* them with the local filesystem isn't going to work properly, since the syntax and semantics are different.
os.fspath(pathlib.WindowsPath(".")) Traceback (most recent call last): ... TypeError: cannot render 'PureWindowsPath' as filesystem path on 'posix' system
(I'm also suggesting replacing "your" with the value of os.name) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
Nick Coghlan wrote:
Similar to my proposal for dealing with DirEntry.path being a bytes-like object, I'd like to suggest raising TypeError in __fspath__ if the request is nonsensical for the currently running system - *nix systems can *manipulate* Windows paths (and vice-versa), but actually trying to *use* them with the local filesystem isn't going to work properly, since the syntax and semantics are different.
That sounds reasonable, since it would be preferable to fail early if you mistakenly pass a PureWindowsPath to e.g. open(). But there needs to be some way to ask a path object for its native string representation, otherwise there would be no point in using foreign path objects at all. -- Greg
On 10 April 2016 at 17:12, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
Nick Coghlan wrote:
Similar to my proposal for dealing with DirEntry.path being a bytes-like object, I'd like to suggest raising TypeError in __fspath__ if the request is nonsensical for the currently running system - *nix systems can *manipulate* Windows paths (and vice-versa), but actually trying to *use* them with the local filesystem isn't going to work properly, since the syntax and semantics are different.
That sounds reasonable, since it would be preferable to fail early if you mistakenly pass a PureWindowsPath to e.g. open().
But there needs to be some way to ask a path object for its native string representation, otherwise there would be no point in using foreign path objects at all.
In addition to the existing "str(pathobj)", a "path" property was recently added for that purpose:
import pathlib pathlib.PureWindowsPath(".") PureWindowsPath('.') pathlib.PureWindowsPath(".").path '.'
(The specific property name was chosen to match os.scandir's DirEntry.path) Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On 10 April 2016 at 08:36, Nick Coghlan <ncoghlan@gmail.com> wrote:
In addition to the existing "str(pathobj)", a "path" property was recently added for that purpose:
import pathlib pathlib.PureWindowsPath(".") PureWindowsPath('.') pathlib.PureWindowsPath(".").path '.'
(The specific property name was chosen to match os.scandir's DirEntry.path)
I believe that under the current proposal, the ".path" property will be removed again in favour of the new protocol, so the only actual option would be str(pathobj). Paul
On 04/10/2016 12:36 AM, Nick Coghlan wrote:
On 10 April 2016 at 17:12, Greg Ewing wrote:
But there needs to be some way to ask a path object for its native string representation, otherwise there would be no point in using foreign path objects at all.
In addition to the existing "str(pathobj)", a "path" property was recently added for that purpose:
>>> import pathlib >>> pathlib.PureWindowsPath(".") PureWindowsPath('.') >>> pathlib.PureWindowsPath(".").path '.'
(The specific property name was chosen to match os.scandir's DirEntry.path)
But with the new __fspath__ enhancements wouldn't the .path attribute go away? -- ~Ethan~
On Apr 10, 2016, at 2:43 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
This does raise a concrete API design question: how should PurePath.__fspath__ behave when called on a mismatched OS?
I think that PurePath.__fspath__ should return a string. There’s no reason why we can’t in my opinion and doing so just limits the usefulness of the method. For instance, it’d prevent it from being possible to serialize a pure windows path and send it over the wire to a process running on a Windows machine, like say if you have a build master running on Linux and a build slave running on Windows. ----------------- Donald Stufft PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA
On 11 April 2016 at 01:50, Donald Stufft <donald@stufft.io> wrote:
On Apr 10, 2016, at 2:43 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
This does raise a concrete API design question: how should PurePath.__fspath__ behave when called on a mismatched OS?
I think that PurePath.__fspath__ should return a string. There’s no reason why we can’t in my opinion and doing so just limits the usefulness of the method. For instance, it’d prevent it from being possible to serialize a pure windows path and send it over the wire to a process running on a Windows machine, like say if you have a build master running on Linux and a build slave running on Windows.
Yeah, given that you have to go out of your way to create a path object for an alternate platform, this makes sense - the "I know what I'm doing" indicator is calling pathlib.Pure[Windows|Posix]Path instead of ""pathlib.PurePath in the first place, and so __fspath__ can just do its thing as a pure text-based operation, without worrying about the current platform. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow <ericsnowcurrently@gmail.com> wrote:
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon <brett@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
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? Now that Windows 10++ will run Ubuntu apps, will Python be able to tell
On 4/8/2016 3:28 PM, Eric Snow wrote: the difference for when it should return Windows-format paths and Posix-format paths? (I'm sure the answer is yes, the Python-for-Ubuntu running on Windows would do the latter, and the Python-for-Windows would do the former. Although, it is not clear what sys.platform will return, yet...)
On Fri, Apr 8, 2016, 16:13 Glenn Linderman <v+python@g.nevcal.com> wrote:
On 4/8/2016 3:28 PM, Eric Snow wrote:
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?
Now that Windows 10++ will run Ubuntu apps, will Python be able to tell the difference for when it should return Windows-format paths and Posix-format paths?
All the bits of code in Python accept / as a separator on Windows so it doesn't matter (but Ubuntu on Windows is Linux, so it will be / just like any other Linux install).
(I'm sure the answer is yes, the Python-for-Ubuntu running on Windows would do the latter, and the Python-for-Windows would do the former. Although, it is not clear what sys.platform will return, yet...)
It should return Linux. -Brett _______________________________________________
Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe: https://mail.python.org/mailman/options/python-dev/brett%40python.org
On Fri, Apr 8, 2016 at 7:41 PM, Brett Cannon <brett@python.org> wrote:
On Fri, Apr 8, 2016, 16:13 Glenn Linderman <v+python@g.nevcal.com> wrote:
On 4/8/2016 3:28 PM, Eric Snow wrote:
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?
Now that Windows 10++ will run Ubuntu apps, will Python be able to tell the difference for when it should return Windows-format paths and Posix-format paths?
All the bits of code in Python accept / as a separator on Windows so it doesn't matter (but Ubuntu on Windows is Linux, so it will be / just like any other Linux install).
Technically it isn't linux. :) It's the Ubuntu user-space using the linux syscalls (like normal), and those syscalls are implemented as light wrappers around the Windows kernel. They even implemented fork. On Windows. There's no linux kernel involved.
(I'm sure the answer is yes, the Python-for-Ubuntu running on Windows would do the latter, and the Python-for-Windows would do the former. Although, it is not clear what sys.platform will return, yet...)
It should return Linux.
From screenshots it looks like lsb_release -a returns the normal Ubuntu info [1] and uname -a says linux (don't know if that will change). [2] So yeah, sys.platform should return Linux.
-eric [1] https://blogs.windows.com/buildingapps/2016/03/30/run-bash-on-ubuntu-on-wind... [2] https://insights.ubuntu.com/2016/03/30/ubuntu-on-windows-the-ubuntu-userspac...
Eric Snow wrote:
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?
What standardized representation? I'm not aware of such a thing.
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.
No, you should get the representation corresponding to the kind of path object you started with. If you're working with Windows path objects on a Unix system, they must be representing something on some Windows system somewhere, not the one you're running the code on. The only reason to ask for a string representation of such a path is for use by that other system. I don't think it even makes sense to ask for a Unix representation of a Windows path or vice versa, because the semantics are different. How do you translate a Windows drive letter into Unix? What drive letter do you use for an absolute Unix path? -- Greg
On 9 April 2016 at 04:25, Brett Cannon <brett@python.org> wrote:
On Fri, 8 Apr 2016 at 11:13 Ethan Furman <ethan@stoneleaf.us> wrote:
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does.
I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of the fact that a path is *not a string*, but rather a string is a *representation* (or serialization) of a path.
That's a decent point.
So the plausible choices are, I think:
- __fspath__ # File System Path -- possible confusion with Path
+1
I like __fspath__, but I'm also sympathetic to Koos' point that we're really dealing with path *names* being produced via this protocol, rather than the paths themselves. That would bring the completely explicit "__fspathname__" into the mix, which would be comparable in length to "__getattribute__" as a magic method name (both in terms of number of syllable and number of characters). Considering the helper function usage, here's some examples in combination with os.fsencode and os.fsdecode: # Status quo for binary/text path conversions text_path = os.fsdecode(bytes_path) bytes_path = os.fsencode(text_path) # Getting a text path from an arbitrary object text_path = os.fspath(obj) # This doesn't scream "returns text!" to me text_path = os.fspathname(obj) # This does # Getting a binary path from an arbitrary object bytes_path = os.fsencode(os.fspath(obj)) bytes_path = os.fsencode(os.fspathname(obj)) I'm starting to think the semantic nudge from the "name" suffix when reading the code is worth the extra four characters when writing it (keeping in mind that the whole point of this exercise is that most folks *won't* be writing explicit conversions - the stdlib will handle it on their behalf). I also think the more explicit name helps answer some of the type signature questions that have arisen: 1. Does os.fspathname return rich Path objects? No, it returns names as str objects 2. Will file descriptors pass through os.fspathname? No, as they're not names, they're numeric descriptors. 3. Will bytes-like objects pass through os.fspathname? No, as they're not names, they're encodings of names When the name is instead "os.fspath", the appropriate answers to those three questions are far more debatable.
I personally still like __ospath__ as well.
That one fails the "Is it ambiguous when spoken aloud?" test for me: if someone mentions "oh-ess-path", are they talking about os.path or __ospath__? With "eff-ess-path" or "eff-ess-path-name", that problem doesn't arise. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
On Sat, 09 Apr 2016 17:48:38 +1000, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 9 April 2016 at 04:25, Brett Cannon <brett@python.org> wrote:
On Fri, 8 Apr 2016 at 11:13 Ethan Furman <ethan@stoneleaf.us> wrote:
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does.
I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of the fact that a path is *not a string*, but rather a string is a *representation* (or serialization) of a path.
That's a decent point.
So the plausible choices are, I think:
- __fspath__ # File System Path -- possible confusion with Path
+1
I like __fspath__, but I'm also sympathetic to Koos' point that we're really dealing with path *names* being produced via this protocol, rather than the paths themselves.
That would bring the completely explicit "__fspathname__" into the mix, which would be comparable in length to "__getattribute__" as a magic method name (both in terms of number of syllable and number of characters).
I'm not going to vote -1, but for the record I have no real intuition as to what a "path name" would be. An arbitrary identifier that we're using to refer to an os path? 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. --David
On 9 April 2016 at 23:02, R. David Murray <rdmurray@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@gmail.com | Brisbane, Australia
On 9 April 2016 at 23:02, R. David Murray <rdmurray@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 term "pathname" is what is conventionally used to refer to a textual string passed to the OS to identify an object in the file system. It's often abbreviated to just "path", but that's ambiguous for our purposes, because "path" can also refer to one of our higher-level objects. -- Greg
On Sun, 10 Apr 2016 18:51:23 +1200, Greg Ewing <greg.ewing@canterbury.ac.nz> wrote:
On 9 April 2016 at 23:02, R. David Murray <rdmurray@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 term "pathname" is what is conventionally used to refer to a textual string passed to the OS to identify an object in the file system.
It's often abbreviated to just "path", but that's ambiguous for our purposes, because "path" can also refer to one of our higher-level objects.
I find it interesting that in all my years of unix computing I've never run into this (at least so that I became concious of it). I see now that in fact the Posix spec uses 'pathname'. Objection, such as it was, completely withdrawn :) (Nick's point about Path object vs path is also a good one.) --David
On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan <ncoghlan@gmail.com> wrote:
On 9 April 2016 at 04:25, Brett Cannon <brett@python.org> wrote:
On Fri, 8 Apr 2016 at 11:13 Ethan Furman <ethan@stoneleaf.us> wrote:
On 04/08/2016 10:46 AM, Koos Zevenhoven wrote:
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
I'm still thinking a little bit about 'pathname', which to me sounds more like a string than fspath does.
I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of the fact that a path is *not a string*, but rather a string is a *representation* (or serialization) of a path.
That's a decent point.
So the plausible choices are, I think:
- __fspath__ # File System Path -- possible confusion with Path
+1
I like __fspath__, but I'm also sympathetic to Koos' point that we're really dealing with path *names* being produced via this protocol, rather than the paths themselves.
That would bring the completely explicit "__fspathname__" into the mix, which would be comparable in length to "__getattribute__" as a magic method name (both in terms of number of syllable and number of characters).
Considering the helper function usage, here's some examples in combination with os.fsencode and os.fsdecode:
# Status quo for binary/text path conversions text_path = os.fsdecode(bytes_path) bytes_path = os.fsencode(text_path)
# Getting a text path from an arbitrary object text_path = os.fspath(obj) # This doesn't scream "returns text!" to me text_path = os.fspathname(obj) # This does
# Getting a binary path from an arbitrary object bytes_path = os.fsencode(os.fspath(obj)) bytes_path = os.fsencode(os.fspathname(obj))
I'm starting to think the semantic nudge from the "name" suffix when reading the code is worth the extra four characters when writing it (keeping in mind that the whole point of this exercise is that most folks *won't* be writing explicit conversions - the stdlib will handle it on their behalf).
Regarding the name, I completely agree with Nick's reasoning (above). I'm not sure it's a high priority to make dunder-method names short. They are not typed very often, and when the number of these "protocols" increases, you face potentially ambiguous names more and more often (there already is a '__path__' and a '__file__' etc., as has been brought up earlier in these threads.). In other words, it's a good idea to have some information in the name.
I also think the more explicit name helps answer some of the type signature questions that have arisen:
1. Does os.fspathname return rich Path objects? No, it returns names as str objects
Or byte strings, it seems, unfortunately.
2. Will file descriptors pass through os.fspathname? No, as they're not names, they're numeric descriptors. 3. Will bytes-like objects pass through os.fspathname? No, as they're not names, they're encodings of names
If fspathname(...) is to be used in os.path.*, it will break things if it starts to turn encoded bytes pathnames into str pathnames, which it did not previously do. And if fspathname is not to be used in os.path.*, who would be our intended user of fspathname? I assume we we don't want to encourage typical 'users' to manipulate pathnames by hand.
I personally still like __ospath__ as well.
That one fails the "Is it ambiguous when spoken aloud?" test for me: if someone mentions "oh-ess-path", are they talking about os.path or __ospath__? With "eff-ess-path" or "eff-ess-path-name", that problem doesn't arise.
+1 to this too. -Koos
participants (15)
-
Antoine Pitrou -
Brett Cannon -
Chris Angelico -
Chris Barker -
Chris Barker - NOAA Federal
-
Donald Stufft -
Eric Snow -
Ethan Furman -
Giampaolo Rodola' -
Glenn Linderman -
Greg Ewing -
Koos Zevenhoven -
Nick Coghlan -
Paul Moore -
R. David Murray