On 04/05/2016 11:57 PM, Nick Coghlan wrote: > On 6 April 2016 at 16:53, Nathaniel Smith <njs at pobox.com> wrote: >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncoghlan at gmail.com> wrote: >>> I'd missed the existing precedent in DirEntry.path, so simply taking >>> that and running with it sounds good to me. >> >> This makes me twitch slightly, because NumPy has had a whole set of >> problems due to the ancient and minimally-considered decision to >> assume a bunch of ad hoc non-namespaced method names fulfilled some >> protocol -- like all .sum methods will have a signature that's >> compatible with numpy's, and if an object has a .log method then >> surely that computes the logarithm (what else in computing could "log" >> possibly refer to?), etc. This experience may or may not be relevant, >> I'm not sure -- sometimes these kinds of twitches are good guides to >> intuition, and sometimes they are just knee-jerk responses to an old >> and irrelevant problem :-) >> >> But you might want to at least think about >> how common it might be to have existing objects with unrelated >> attributes that happen to be called "path", and the bizarro problems >> that might be caused if someone accidentally passes one of them to a >> function that expects all .path attributes to be instances of this new >> protocol. > > sys.path, for example. > > That's why I'd actually prefer the implicit conversion protocol to be > the more explicitly named "__fspath__", with suitable "__fspath__ = > path" assignments added to DirEntry and pathlib. However, I'm also not > offering to actually *do* the work here, and the casting vote goes to > the folks pursuing the implementation effort. If we decide upon __fspath__ (or __path__) I will do the work on pathlib and scandir to add those attributes. -- ~Ethan~
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