On Wed, 6 Apr 2016 at 10:36 Michel Desmoulin <desmoulinmic...@gmail.com> wrote:
> Wouldn't be better to generalize that to a "__location__" protocol, > which allow to return any kind of location, including path, url or > coordinate, ip_address, etc ? > No because all of those things have different semantic meaning. See the __index__ PEP for reasons why you would tightly bound protocols instead of overloading ones like __int__ for multiple meanings. -Brett > > Le 06/04/2016 19:26, Brett Cannon a écrit : > > WIth Ethan volunteering to do the work to help make a path protocol a > > thing -- and I'm willing to help along with propagating this through the > > stdlib where I think Serhiy might be interested in helping as well -- > > and a seeming consensus this is a good idea, it seems like this proposal > > has a chance of actually coming to fruition. > > > > Now we need clear details. :) Some open questions are: > > > > 1. Name: __path__, __fspath__, or something else? > > 2. Method or attribute? (changes what kind of one-liner you might use > > in libraries, but I think historically all protocols have been > > methods and the serialized string representation might be costly to > > build) > > 3. Built-in? (name is dependent on #1 if we add one) > > 4. Add the method/attribute to str? (I assume so, much like __index__() > > is on int, but I have not seen it explicitly stated so I would > > rather clarify it) > > 5. Expand the C API to have something like PyObject_Path()? > > > > > > Some people have asked for the pathlib PEP to have a more flushed out > > reasoning as to why pathlib doesn't inherit from str. If Antoine doesn't > > want to do it I can try to instil my blog post into a more succinct > > paragraph or two and update the PEP myself. > > > > Is this going to require a PEP or if we can agree on the points here are > > we just going to do it? If we think it requires a PEP I'm willing to > > write it, but I obviously have no issue if we skip that step either. :) > > > > Oh, and we should resolve this before the next release of Python 3.4, > > 3.5, or 3.6 so that pathlib can be updated in those releases. > > > > -Brett > > > > > > On Wed, 6 Apr 2016 at 08:09 Ethan Furman <et...@stoneleaf.us > > <mailto: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 > > <mailto:n...@pobox.com>> wrote: > > >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan <ncogh...@gmail.com > > <mailto: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. > > > > > > > > _______________________________________________ > > 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/desmoulinmichel%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
