-- Ryan [ERROR]: Your autotools build scripts are 200 lines longer than your program. Something’s wrong. http://kirbyfan64.github.io/ On Apr 6, 2016 12:28 PM, "Brett Cannon" <br...@python.org> wrote: > > 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:
My votes: > Name: __path__, __fspath__, or something else? __path__. Considering everything related to `pathlib` uses the word `path`, __fspath__ seems kind of odd. > 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) Method. Using an attribute would be needlessly inconsistent. > Built-in? (name is dependent on #1 if we add one) > 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) I agree; this would avoid lots of excess complexity. > Expand the C API to have something like PyObject_Path()? -1. PyFileObject was already removed from Python 3; it seems useless to add another one. > > 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> 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. > > > _______________________________________________ > 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/rymg19%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/archive%40mail-archive.com
