On 6 April 2016 at 16:53, Nathaniel Smith <n...@pobox.com> wrote: > On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncogh...@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. Cheers, Nick. -- Nick Coghlan | ncogh...@gmail.com | Brisbane, Australia _______________________________________________ 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/archive%40mail-archive.com
