On Fri, 8 Apr 2016 at 09:05 Chris Barker <chris.bar...@noaa.gov> wrote:
> On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan <ncogh...@gmail.com> wrote: > >> On 7 April 2016 at 03:26, Brett Cannon <br...@python.org> wrote: >> > > >> > 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) >> > > couldn't it be a property? > A property is a method pretending to be an attribute, so yes. :) > > >> Method, as long as there's a helper function somewhere > > > what has the helper function got to do with whether it's a method or > attribute (would we call a property an attribute here?) > Yes, a property is an attribute in this instance. And it somewhat tweaks how simple of a one-liner is needed which in turn makes the function either nearly redundant or helpful. With an attribute: getattr(path, '__ospath__', path) With a method: path.__ospath__() if hasattr(path, '__ospath__') else path > > > Built-in? (name is dependent on #1 if we add one) >> >> os.fspath (alongside os.fsencode and os.fsdecode) >> >> (Putting this in a module low in the dependency stack makes it easy >> for other modules to access without pulling in all of pathlib's >> dependencies) > > > Iike that -- though still =0.5 on having one at all -- this is only going > to be used by the stdlib and other path-using libraries, not user code -- > is that that hard to call obj.__fspath__() ? > With a function we can add some type checking so that you know you are getting back a string and not something else like an file descriptor int or something. > > > 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 thought the whole point off all this is that not any old string can be a > path! (whereas any int can be an index). Unless we go with Chris A's > suggestion that this be a more generic lossless string protocol, rather > than just for paths. > The whole point is to not treat a path object like any old string. We still have to support a string someone created that is a valid path. Remember, what we're trying to avoid is people simply doing `str(path)` everywhere since that works with e.g. None. > > >> It's worth summarising in a PEP at least for communications purposes - >> very easy for folks that don't follow python-dev to miss otherwise. >> > > I'd say add it to the existing pathlib PEP -- along with the extra > discussion of why Path does not inherit from str. > That's the plan. -Brett > > -CHB > > > > -- > > Christopher Barker, Ph.D. > Oceanographer > > Emergency Response Division > NOAA/NOS/OR&R (206) 526-6959 voice > 7600 Sand Point Way NE (206) 526-6329 fax > Seattle, WA 98115 (206) 526-6317 main reception > > chris.bar...@noaa.gov >
_______________________________________________ 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