On Wed, 6 Apr 2016 at 10:41 Wes Turner <wes.tur...@gmail.com> wrote: > * +1 for __path__, __fspath__ > (though I don't know what each does) >
Returns a string representing a file system path. > * why not Text(basestring / bytestring) and pathlib.Path(Text)? > See the points about next() vs __next__() > * are there examples of cases where this cannot be? > I don't understand what you think "cannot be". > * if not, +1 for subclassing str/Text > > * where are the examples of method collisions between the str > interface and the pathlib.Path interface? > There aren't any and that's partially why some people wanted the str subclass to begin with. Please consider this thread a str-subclass-free zone. This line of discussion is to flesh out the proposal for a path protocol as a proposal against subclassing str, not to settle the whole discussion outright. If you want to continue to debate the subclassing-str side of this please use the other thread. -Brett > * str.__div__ is nonsensical > * pathlib.Path.__div__ is super-useful > > > On Apr 6, 2016 10:10 AM, "Ethan Furman" <et...@stoneleaf.us> wrote: > >> On 04/05/2016 11:57 PM, Nick Coghlan wrote: >> >>> 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. >>> >> >> If we decide upon __fspath__ (or __path__) I will do the work on pathlib >> and scandir to add those attributes. >> >> -- >> ~Ethan~ >> _______________________________________________ >> 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/wes.turner%40gmail.com >> > _______________________________________________ > 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 >
_______________________________________________ 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