On 04/06/2016 08:53 AM, Nathaniel Smith wrote: > On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncogh...@gmail.com> wrote: >> On 6 April 2016 at 15:57, Serhiy Storchaka <storch...@gmail.com> wrote: >>> On 06.04.16 05:44, Nick Coghlan wrote: >>>> >>>> The most promising option for that is probably "getattr(path, 'path', >>>> path)", since the "path" attribute is being added to pathlib, and the >>>> given idiom can be readily adopted in Python 2/3 compatible code >>>> (since normal strings and any other object without a "path" attribute >>>> are passed through unchanged). Alternatively, since it's a protocol, >>>> double-underscores on the property name may be appropriate (i.e. >>>> "getattr(path, '__path__', path)") >>> >>> This was already discussed. Current conclusion is using the "path" >>> attribute. See http://bugs.python.org/issue22570 . >> >> 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. > > -n >
Python was in a similar situation with the .next method on iterators, which changed to __next__ in Python 3. PEP 3114 (which explains this change) says: > Code that nowhere contains an explicit call to a next method can > nonetheless be silently affected by the presence of such > a method. Therefore, this PEP proposes that iterators should have > a __next__ method instead of a next method (with no change in > semantics). How well does that apply to path/__path__? That PEP also introduced the next() builtin. This suggests that a protocol with __path__/__fspath__ would need a corresponding path()/fspath() builtin. _______________________________________________ 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
