On Wed, 6 Apr 2016 at 14:03 Wes Turner <wes.tur...@gmail.com> wrote: > > On Apr 6, 2016 12:47 PM, "Brett Cannon" <br...@python.org> wrote: > > > > > > > > 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 two methods? __uripath__? > > (scheme, host (port), path, query, fragment) so, not __uripath__ > > what would be the difference between __path__ and __fspath__? >
There is no difference; we're trying to choose a name. > > > >> > >> * why not Text(basestring / bytestring) and pathlib.Path(Text)? > > > > > > See the points about next() vs __next__() > > Path(b'123') / u'456' > > similarly, > Path(b'123') / UTF8 / UTF16 > As other people pointed out on the other thread, while bytes paths do exist, we don't want to promote them as they are a mess to work with. -Brett > > > >> > >> * are there examples of cases where this cannot be? > > > > > > I don't understand what you think "cannot be". > > What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is > distinct from what any given programmer chooses to do with their code. > > > > >> > >> * 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. > > this seems to be a sudden, arbitrary distinction. > > are these proposals necessarily disjoint? > > so, > adding getattr(path, '__path__', path) to stdlib and other code is going > to prevent which edge cases (before os.path.normpath()* anyway) for which > benefit? > > when do I do getattr(path, '__fspath__', path)? > > > > > -Brett > > > >> > >> * str.__div__ is nonsensical > >> * pathlib.Path.__div__ is super-useful > > ah, not .__add__() but .append() > > I suppose the request here is for the cases which would be prevented (that > we need to learn to look for) > > >> > >> > >> > >> 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