[issue22570] Better stdlib support for Path objects using .path attribute

Changes by Ethan Furman : -- nosy: +ethan.furman title: Better stdlib support for Path objects -> Better stdlib support for Path objects using .path attribute ___ Python tracker ___

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Done. The revs are 90e58a77d386, 97198545e6c3, ade839421b8f. -- resolution: out of date -> fixed status: open -> closed ___ Python tracker ___

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: And those from http://bugs.python.org/issue22570#msg257632 (these are the actual code -- the others were the docs). -- ___ Python tracker ___

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: PEP 519 is accepted now. We need to revert the commits from http://bugs.python.org/issue22570#msg257634 -- ___ Python tracker ___ ___

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Reopening as we need to rename the path attribute to __fspath__ once Brett's PEP is accepted (which will be soon). https://github.com/brettcannon/path-pep/blob/master/pep-0NNN.rst The 3.4 and 3.5 versions of this should probably just be reversed before their

[issue22570] Better stdlib support for Path objects

Serhiy Storchaka added the comment: Sorry, these changesets were related to issue26200. -- ___ Python tracker ___ ___ Python-bugs-list

[issue22570] Better stdlib support for Path objects

Roundup Robot added the comment: New changeset d0c8b2c1544e by Serhiy Storchaka in branch '3.5': Issue #22570: Renamed Py_SETREF to Py_XSETREF. https://hg.python.org/cpython/rev/d0c8b2c1544e New changeset 719c11b6b6ff by Serhiy Storchaka in branch 'default': Issue #22570: Renamed Py_SETREF to Py

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: You can't win 'em all... :-) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22570] Better stdlib support for Path objects

Serhiy Storchaka added the comment: > str(arg.path) if hasattr(arg, 'path') else arg DirEntry.path can be bytes. -- ___ Python tracker ___ __

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Using 'path' for this field is not a misnomer (example: DictEntry uses 'path' for the same field). See issue #26027 for a follow-up idea. -- dependencies: -Support Path objects in the posix module resolution: -> fixed stage: -> resolved status: op

[issue22570] Better stdlib support for Path objects

Brett Cannon added the comment: I appreciate the thought, Ram, but I'm not a fan. -- ___ Python tracker ___ ___ Python-bugs-list maili

[issue22570] Better stdlib support for Path objects

Ram Rachum added the comment: Here's an alternate idea I thought of now. Maybe `path.path` should be a pointer to the same `Path` object, so every function will do this: str(arg.path) if hasattr(arg, 'path') else arg What I like about this is that it avoids having the path argument be a s

[issue22570] Better stdlib support for Path objects

Changes by R. David Murray : -- nosy: -r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Let's say that the path attribute should be str or bytes -- this matches the behavior of DirEntry. (But for pathlib.Path it is always a str.) It cannot be None or FD. But note that the getattr(x, 'path', x) idiom returns x unchanged if x is None or an FD (or a

[issue22570] Better stdlib support for Path objects

Serhiy Storchaka added the comment: Opened issue26027 for adding support in the posix module. Should the path attribute be only string, or other types are acceptable (bytes, file descriptor, and even None if the function accepts None)? -- dependencies: +Support Path objects in the posi

[issue22570] Better stdlib support for Path objects

Brett Cannon added the comment: We could leave this open as a meta issue and spin off individual issues for any specific module people choose to update to support Path objects, setting those new issues as dependencies here. -- ___ Python tracker

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: So, I added docs, mentioning the getattr(arg, 'path', arg) idiom, and (for 3.5 and 3.6) also cross-referencing with DirEntry. I'm not sure whether to now close this issue or whether to leave it open to remind people of adding patches using the new idiom to v

[issue22570] Better stdlib support for Path objects

Roundup Robot added the comment: New changeset 2e3c31ab586a by Guido van Rossum in branch '3.4': Docs for issue #22570. https://hg.python.org/cpython/rev/2e3c31ab586a New changeset 408f8b255b56 by Guido van Rossum in branch '3.5': Docs for issue #22570. (Merge 3.4->3.5) https://hg.python.org/cpy

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: No docs? ;) -- ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue22570] Better stdlib support for Path objects

Roundup Robot added the comment: New changeset 7e9605697dfc by Guido van Rossum in branch '3.4': Issue #22570: Add 'path' attribute to pathlib.Path objects. https://hg.python.org/cpython/rev/7e9605697dfc New changeset 9c49c417a68a by Guido van Rossum in branch '3.5': Issue #22570: Add 'path' att

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: OK, I'll add 'path' to unblock changes to the stdlib (but I won't close this issue). -- ___ Python tracker ___ ___

[issue22570] Better stdlib support for Path objects

Antoine Pitrou added the comment: In any case I don't think "location" is any better ;-) If "path" fits other people then good. -- ___ Python tracker ___ ___

[issue22570] Better stdlib support for Path objects

Brett Cannon added the comment: Personally I thought the name `path` fit; just trying to see if some other option might work that Antoine would also like. -- ___ Python tracker

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Only if we changed DirEntry to support that too. But it's a kind of high-falootin' word that also has some other connotations (e.g. geographical location, and the HTTP Location header). I've never heard it use in relation to filenames -- those are invariably ca

[issue22570] Better stdlib support for Path objects

Brett Cannon added the comment: Would `location` work as an attribute name? -- ___ Python tracker ___ ___ Python-bugs-list mailing lis

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: I think it's actually very reasonable for a Path to have a path attribute that's a string. The DirEntry has two string attributes: name (the last component) and path (the full path). The Path object already has the former. Adding the latter makes sense to me. A

[issue22570] Better stdlib support for Path objects

Antoine Pitrou added the comment: Here the aim is really to distinguish path-like objects from other objects, not to accept arbitrary strings. A ".path" attribute sounds like the wrong name, though: a Path has a path? And the Path's path is not a Path? Ouch :-) -- ___

[issue22570] Better stdlib support for Path objects

Serhiy Storchaka added the comment: `str(object)` is not a protocol for getting a string out of an object. It's a protocol for getting a string for print(). __str__ is defined for every object and therefore is useless for getting a string out of "string-like" object (as __float__ for floats an

[issue22570] Better stdlib support for Path objects

Ram Rachum added the comment: I thought about it some more, and personally I'd prefer each function to do `str(path)` internally rather than `if hasattr(p, 'path'): p = p.path`. Even if it means we'll have to deal with "where did that file named '' come from?!" errors. I think it's clumsy that

[issue22570] Better stdlib support for Path objects

Guido van Rossum added the comment: Random idea: what if pathlib.Path defined a .path attribute that was a plain string? Then you could write p.path instead of str(p), and "if hasattr(p, 'path'): p = p.path". This would be the new protocol. Advantage is also that DirEntry (returned by the new

[issue22570] Better stdlib support for Path objects

Torsten Bronger added the comment: Please be conservative with adding methods to Path. FWIW, my own experiences with pathlib have shown that utility methods have the disadvantage of duplicating well-established Python idioms. This reduces code readability in my opinion. While it is desirable

[issue22570] Better stdlib support for Path objects

Changes by Torsten Bronger : -- nosy: +bronger ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue22570] Better stdlib support for Path objects

Changes by Ugra Dániel : -- nosy: +daniel.ugra ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyt

[issue22570] Better stdlib support for Path objects

Changes by Arfrever Frehtes Taifersar Arahesis : -- nosy: +Arfrever ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscri

[issue22570] Better stdlib support for Path objects

Antoine Pitrou added the comment: > I'm -1 on just sprinkling support for Path throughout the stdlib. > Do it in a universally applicable fashion or don't do it at all, IMO. How about doing it per module? -- ___ Python tracker

[issue22570] Better stdlib support for Path objects

R. David Murray added the comment: Well, if you use an isinstance check you privilege the stdlib Path over any other pathlike implementation. Since it *is* in the stdlib, this isn't an automatic reason for rejection, but it does have a bit of a code smell to it. Why should everything that de

[issue22570] Better stdlib support for Path objects

Ram Rachum added the comment: Georg: You're right, I forgot about C modules which make this not as trivial as I thought. As for Python modules: If there's general agreement that this is a feature we want, I'll be happy to make a patch for the `zipfile` module to accept `Path` arguments.

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: > Making old functions support `Path` sounds trivial to me We're looking forward to trivial patches that enable Path handling consistently throughout the stdlib. > Fine, so you add an `if isinstance...` in front of it and you're done. Easier said than done in C

[issue22570] Better stdlib support for Path objects

Ram Rachum added the comment: Fine, so you add an `if isinstance...` in front of it and you're done. -- ___ Python tracker ___ ___ Pyt

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: `path = str(path)` is minimal, but has the side effect of accepting almost any object, which is definitely not what you'd like ("where did that file named '' come from?!") -- ___ Python tracker

[issue22570] Better stdlib support for Path objects

Ram Rachum added the comment: I agree with Brett. Making old functions support `Path` sounds trivial to me, and I don't think there are any backward compatibility issues. Having to do str(path) every time you call a function is ugly. So I think that all stdlib functions that currently take a s

[issue22570] Better stdlib support for Path objects

Changes by Tshepang Lekhonkhobe : -- nosy: +tshepang ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://ma

[issue22570] Better stdlib support for Path objects

Changes by Ezio Melotti : -- nosy: +ezio.melotti type: -> enhancement ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubs

[issue22570] Better stdlib support for Path objects

Brett Cannon added the comment: I think I'm missing something here because the idea of doing `path = str(path)` at the API boundary for an old function to support both Path and str objects for paths seems fairly minimal. Only when manipulating a path is wanting a Path object going to come up,

[issue22570] Better stdlib support for Path objects

Changes by R. David Murray : -- nosy: +r.david.murray ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue22570] Better stdlib support for Path objects

Antoine Pitrou added the comment: As for adding convenience methods to Path objects, yes, I'm quite open to that. Best is to open an issue when you have a specific idea (and a patch :-)). -- ___ Python tracker ___

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: > That would be a rather horrible solution. I know :) -- ___ Python tracker ___ ___ Python-bugs-list

[issue22570] Better stdlib support for Path objects

Antoine Pitrou added the comment: > I was about to suggest deriving your own Path class from Path and str That would be a rather horrible solution. It has already been suggested to create a "path protocol". I would suggest Barry tries to float and investigate the idea on python-ideas: https://m

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: I was about to suggest deriving your own Path class from Path and str, but got a base class layout conflict because Path objects define lots of __slots__ :( -- ___ Python tracker __

[issue22570] Better stdlib support for Path objects

Barry A. Warsaw added the comment: On Oct 06, 2014, at 03:43 PM, Georg Brandl wrote: >I'd rather write str(path) all over the place than having to look up in the >docs each time if that specific API happens to support passing Paths >directly. Have you tried to write a large-ish application usin

[issue22570] Better stdlib support for Path objects

Georg Brandl added the comment: Since we're unlikely to ever change all the places, I'd say it's better to be consistent. I'd rather write str(path) all over the place than having to look up in the docs each time if that specific API happens to support passing Paths directly. However, Antoin

[issue22570] Better stdlib support for Path objects

Changes by Barry A. Warsaw : -- nosy: +pitrou ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://mail.pyth

[issue22570] Better stdlib support for Path objects

Changes by Barry A. Warsaw : -- components: +Library (Lib) ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: http

[issue22570] Better stdlib support for Path objects

New submission from Barry A. Warsaw: pathlib is really nice, but currently it's rather inconvenient to use due to the lack of support in other parts of the stdlib for Path objects. For historical reasons, everything accepts string paths, but few places accept Paths. As an example: configpars