On Wed, 6 Apr 2016 at 15:54 Gregory P. Smith <g...@krypto.org> wrote:
> Note: While I do not object to the bike shed colors being proposed, if you > call the attribute .__path__ that is somewhat confusing when thinking about > the import system which declares that *"any module that contains a > __path__ attribute is considered a package"*. > > So would module.__path__ become a Path instance in a potential future > making module.__path__.__path__ meaningfully confusing? ;) > > I'm not worried about people who shove pathlib.Path instances in as values > into sys.modules and expect anything but pain. :P > Ah, good point. I think that kills __path__ then as an option. -Brett > > __gps__ > > > > On Wed, Apr 6, 2016 at 3:46 PM Brett Cannon <br...@python.org> wrote: > >> On Wed, 6 Apr 2016 at 15:22 Paul Moore <p.f.mo...@gmail.com> wrote: >> >>> On 6 April 2016 at 20:39, Brett Cannon <br...@python.org> wrote: >>> >> I'm a little confused by this. To support the older pathlib, they have >>> >> to do patharg = str(patharg), because *none* of the proposed >>> >> attributes (path or __path__) will exist. >>> >> >>> >> The getattr trick is needed to support the *new* pathlib, when you >>> >> need a real string. Currently you need a string if you call stdlib >>> >> functions or builtins. If we fix the stdlib/builtins, the need goes >>> >> away for those cases, but remains if you need to call libraries that >>> >> *don't* support pathlib (os.path will likely be one of those) or do >>> >> direct string manipulation. >>> >> >>> >> In practice, I see the getattr trick as an "easy fix" for libraries >>> >> that want to add support but in a minimally-intrusive way. On that >>> >> basis, making the trick easy to use is important, which argues for an >>> >> attribute. >>> > >>> > So then where's the confusion? :) You seem to get the points. I >>> personally >>> > find `path.__path__() if hasattr(path, '__path__') else path` also >>> readable >>> > (if obviously a bit longer). >>> >>> The confusion is that you seem to be saying that people can use >>> getattr(path, '__path__', path) to support older versions of Python. >>> But the older versions are precisely the ones that don't have __path__ >>> so you won't be supporting them. >>> >> >> Because pathlib is provisional the change will go into the next releases >> of Python 3.4, 3.5, and in 3.6 so new-old will have whatever we do. :) I >> think the key point is that this sort of thing will occur before you have >> access to some new built-in or something. >> >> >>> >>> >> >> > 3. Built-in? (name is dependent on #1 if we add one) >>> >> >> >>> >> >> fspath() -- and it would be handy to have a function that return >>> either >>> >> >> the __fspath__ results, or the string (if it was one), or raise an >>> >> >> exception if neither of the above work out. >>> >> >>> >> fspath regardless of the name chosen in #1 - a new builtin called path >>> >> just has too much likelihood of clashing with user code. >>> >> >>> >> But I'm not sure we need a builtin. I'm not at all clear how >>> >> frequently we expect user code to need to use this protocol. Users >>> >> can't use the builtin if they want to be backward compatible, But code >>> >> that doesn't need backward compatibility can probably just work with >>> >> pathlib (and the stdlib support for it) directly. For display, the >>> >> implicit conversion to str is fine. For "get me a string representing >>> >> the path", is the "path" attribute being abandoned in favour of this >>> >> special method? >>> > >>> > Yes. >>> >>> OK. So the idiom to get a string from a known Path object would be any >>> of: >>> >>> 1. str(path) >>> 2. fspath(path) >>> 3. path.__path__() >>> >>> (1) is safe if you know you have a Path object, but could incorrectly >>> convert non-Path objects. (2) is safe in all cases. (3) is ugly. Did I >>> miss any options? >>> >> >> Other than path.__path__ being an attribute, nope. >> >> >>> >>> So I think we need a builtin. >>> >> >> Well, the ugliness shouldn't survive forever if the community shifts over >> to using pathlib while the built-in will. We also don't have a built-in for >> __index__() so it depends on whether we expect this sort of thing to be the >> purview of library authors or if normal people will be interacting with it >> (it's probably both during the transition, but I don't know afterwards). >> >> >>> >>> Code that needs to be backward compatible will still have to use >>> str(path), because neither the builtin nor the __path__ protocol will >>> exist in older versions of Python. >> >> >> str(path) will definitely work, path.__path__ will work if you're running >> the next set of bugfix releases. fspath(path) will only work in Python 3.6 >> and newer. >> >> >>> Maybe a compatibility library could >>> add >>> >>> try: >>> fspath >>> except NameError: >>> try: >>> import pathlib >>> def fspath(p): >>> if isinstance(p, pathlib.Path): >>> return str(p) >>> return p >>> except ImportError: >>> def fspath(p): >>> return p >>> >>> It's messy, like all compatibility code, but it allows code to use >>> fspath(p) in older versions. >>> >> >> I would tweak it to check for __fspath__ before it resorted to calling >> str(), but yes, that could be something people use. >> >> >>> >>> >> I'm inclined to think that if you are writing "pure >>> >> pathlib" code, pathobj.path looks more readable than fspath(pathobj) - >>> >> certainly no *less* readable. >>> > >>> > I don't' know what you mean by "pure pathlib". You mean code that only >>> works >>> > with pathlib objects? Or do you mean code that accepts pathlib objects >>> but >>> > uses strings internally? >>> >>> I mean code that knows it has a Path object to work with (and not a >>> string or anything else). But the point is moot if the path attribute >>> is going away. >>> >>> Other than to say that I do prefer the name "path", I just don't think >>> it's a reasonable name for a builtin. Even if it's OK for user >>> variables to have the same name as builtins, IDEs tend to colour >>> builtins differently, which is distracting. (Temporary variables named >>> "file" or "dir" are the ones I hit frequently...) >>> >>> If all we're debating is the name, though, I think we're pretty much >>> there :-) >>> >> >> It seems like __fspath__ may be leading as a name, but not that many >> people have spoken up. But that is not the only thing still up for debate. >> :) >> >> We have not settled on whether a built-in is necessary. Maybe whatever >> function we come with should live in pathlib itself and not have it be a >> built-in? >> >> We have also not settled on whether __fspath__ should be a method or >> attribute as that changes the boilerplate one-liner people may use if a >> built-in isn't available. This is the first half of the protocol. >> >> What exactly should this helper function do? E.g. does it simply return >> its argument if __fspath__ isn't defined, or does it check for __fspath__, >> then if it's an instance of str, then TypeError? This is the second half of >> the protocol and will end up defining what a "path-like object" represents. >> > _______________________________________________ >> 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/greg%40krypto.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
