Re: [Python-Dev] Defining a path protocol

[Stephen J. Turnbull]

Ethan Furman writes:

 > It means the stuff in place won't change, but the stuff we're
 > adding now to integrate with Path will only support str (which is
 > one reason why os.path isn't going to die).

I don't think this is a reason for keeping os.path.  (Backward
compatibility with existing code is sufficient, of course.)  Support
of str for all file names is provided by PEP 383.  ISTM there's no big
loss to using PEP 383's 'surrogateescape' handler to allow un-decode-
able filenames in pathlib.Path: they're very rare.  AFAIK pathlib
doesn't care about surrogates -- after all, they're entirely
"consenting adults" stuff.  Of course that detracts a bit from the
attractiveness of pathlib.Path vs. os.path or bytes methods, but only
for a use case most people won't encounter in practice.

We continue to support bytes at the os/io/open level for the same
reasons you added formatting back to bytes: there are times when it's
as least as natural to work with bytes as str (eg, when the path is
passed around without manipulation) and more convenient (eg, you don't
have to deal with encodings and UnicodeError handling).

 > After all, the idea is to make these things work with the stdlib, and 
 > the stdlib accepts bytes for path strings.

I don't see a problem.  In dealing with legacy data (archives that
include paths, such as .zips and .isos) we may find un-decode-able
paths, or paths that are decode-able but by undetermined encoding, for
a while to come (decades).  For those, the bytes interfaces are
preferable to unlovely expedients like decoding as 'iso8859-1'.  But
those are specialized use cases.

Sane people dealing with current file systems won't need bytes in
pathlib, and most "out of bounds" uses for pathlib I can think of in
my own experience will be able to use surrogateescape.

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/09/2016 07:32 AM, Nikolaus Rath wrote:

On Apr 07 2016, Donald Stufft  wrote:

On Apr 7, 2016, at 6:48 AM, Nikolaus Rath  wrote:

Does anyone anticipate any classes other than those from pathlib to come
with such a method?



It seems like it would be reasonable for pathlib.Path to call fspath on the
path passed to pathlib.Path.__init__, which would mean that if other libraries
implemented __fspath__ then you could pass their path objects to pathlib and
it would just work (and similarly, if they also called fspath it would enable
interoperation between all of the various path libraries).


Indeed, but my question is: is this actually going to happen? Are there
going to be other libraries that will implement __fspath__, and will
there be demand for pathlib to support them?


There will be at least one.  :)

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Ethan Furman]

On 04/09/2016 03:51 AM, Koos Zevenhoven wrote:

On Sat, Apr 9, 2016 at 10:16 AM, Ethan Furman  wrote:



3.5.0 scandir supports bytes:


Maybe it's the bytes support in scandir that should be deprecated?
(And not bytes support in general, which cannot be done on posix, as I
hear Stephen T. will tell me).


No, scandir is a low-level function -- it needs to support bytes.

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Nikolaus Rath]

On Apr 07 2016, Donald Stufft  wrote:
>> On Apr 7, 2016, at 6:48 AM, Nikolaus Rath  wrote:
>> 
>> Does anyone anticipate any classes other than those from pathlib to come
>> with such a method?
>
>
> It seems like it would be reasonable for pathlib.Path to call fspath on the
> path passed to pathlib.Path.__init__, which would mean that if other libraries
> implemented __fspath__ then you could pass their path objects to pathlib and
> it would just work (and similarly, if they also called fspath it would enable
> interoperation between all of the various path libraries).

Indeed, but my question is: is this actually going to happen? Are there
going to be other libraries that will implement __fspath__, and will
there be demand for pathlib to support them?


Best,
-Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«


signature.asc
Description: PGP signature
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Koos Zevenhoven]

On Sat, Apr 9, 2016 at 10:16 AM, Ethan Furman  wrote:
> On 04/09/2016 12:07 AM, Victor Stinner wrote:
>>
>> os.DirEntry doesn't support bytes: os.scandir() only accept str. It's a
>> deliberate choice.
>
>
> 3.5.0 scandir supports bytes:
>
> --> huh = list(scandir(b'.'))
> --> huh
> [, ,  b'__MACOSX'>, , ,  b'index.html'>]
>
> --> huh[0].path
> b'./minicourse-ajax-project'
>
>

Maybe it's the bytes support in scandir that should be deprecated?
(And not bytes support in general, which cannot be done on posix, as I
hear Stephen T. will tell me).

-Koos
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Ethan Furman]

On 04/09/2016 12:07 AM, Victor Stinner wrote:

os.DirEntry doesn't support bytes: os.scandir() only accept str. It's a
deliberate choice.


3.5.0 scandir supports bytes:

--> huh = list(scandir(b'.'))
--> huh
[, , b'__MACOSX'>, , , b'index.html'>]


--> huh[0].path
b'./minicourse-ajax-project'

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Victor Stinner]

os.DirEntry doesn't support bytes: os.scandir() only accept str. It's a
deliberate choice.

I strongly suggest to only support Unicode for filenames in Python 3. So
__fspath__ must only return str, or a TypeError must be raised.

Victor
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Nick Coghlan]

On 9 April 2016 at 02:02, Koos Zevenhoven  wrote:
> I'm still thinking a little bit about 'pathname', which to me sounds
> more like a string than fspath does [1]. It would be nice to have the
> string/path distinction especially when pathlib adoption grows larger.
> But who knows, maybe somewhere in the far future, no-one will care
> much about fspath, fsencode, fsdecode or os.path.

Ah, I like it - adding the "name" suffix nicely distinguishes the
protocol from the rich path objects in pathlib.

I'll catch up on Ethan's dedicated naming thread before commenting
further, though :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/08/2016 04:05 PM, Koos Zevenhoven wrote:

On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote:

On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:

At this point no one wants to touch bytes paths. If you need that level of
control because of multiple encodings within a single file system then you
will probably have to stick with managing bytes paths on your own to get the
encoding right.


What does this mean? I assume you don't mean os.path.* would stop
dealing with bytes?


No, it does not mean that.  It means the stuff in place won't change, 
but the stuff we're adding now to integrate with Path will only support 
str (which is one reason why os.path isn't going to die).



And if not, then you seem to mean that os.fspath
would do nothing except call .__fspath__().


Fair point.  So it should be something like this:

def fspath(thing):
# look for path attribute
string = getattr(thing, '__fspath__', None)
if string is not None:
return string
# not found, do we have a str or bytes object?
if isinstance(thing, (str, bytes)):
return thing
raise TypeError('`thing` must implement the __fspath__ protocol or 
be an instance of str or bytes')




And just because DirEntry supports bytes doesn't mean that any magic method
it gains has to carry that forward (it can always raise a TypeError if
necessary).


No, but what if some code gets pathnames from whatever other places
and passes them on to os.scandir. Whenever it happens to get a bytes
path, a TypeError gets raised, but only when it picks one of the
DirEntry objects and for instance tries to open(...) it. Of course,
I'm not sure how common this is.


Yeah, I don't think this is a good idea.  Given that fspath() should be 
able to return bytes if bytes are passed in,  DirEntry's __fspath__ 
could return bytes to no ill effect.


I realize this may not be ideal, but throwing bytes to the wind is going 
to bite us in the end.


After all, the idea is to make these things work with the stdlib, and 
the stdlib accepts bytes for path strings.


--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Koos Zevenhoven]

On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon  wrote:
> On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven  wrote:
>
> At this point no one wants to touch bytes paths. If you need that level of
> control because of multiple encodings within a single file system then you
> will probably have to stick with managing bytes paths on your own to get the
> encoding right.

What does this mean? I assume you don't mean os.path.* would stop
dealing with bytes? And if not, then you seem to mean that os.fspath
would do nothing except call .__fspath__(). In that case, I think we
should go back to it being an attribute (or property) and a variation
of the now very famous idiom getattr(path, '__fspath__', path) and
perhaps have os.fspath do exactly that.

> And just because DirEntry supports bytes doesn't mean that any magic method
> it gains has to carry that forward (it can always raise a TypeError if
> necessary).

No, but what if some code gets pathnames from whatever other places
and passes them on to os.scandir. Whenever it happens to get a bytes
path, a TypeError gets raised, but only when it picks one of the
DirEntry objects and for instance tries to open(...) it. Of course,
I'm not sure how common this is.

> It really depends on how we choose to structure the
> function in terms of just doing the right thing for objects that follow the
> protocol or if we want to introduce some required structure for the
> resulting path and implement some type guarantees so you have a better idea
> of what you will be working with after calling the function.

Do you have an example of potential 'required structure'?

>> Then the options are either to return Union[str, bytes] or to
>> always return str. And if the latter does not cause any problems, I
>> like it way better, and it seems others would do too.
>
> You don't have to convert byte paths to str, you can simply raise an
> exception in the face of them.
>

I thought the point was for existing APIs to start supporting path
objects, wouldn't raising an exception break the API?

-Koos
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven  wrote:

> On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon  wrote:
> > On Fri, 8 Apr 2016 at 09:39 Ethan Furman  wrote:
> >> > 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.
> >>
> >> That does seem to be a valid point against str.__fspath__.
> >
> > Yep, and I'm expecting we won't want that at this point. The fact that
> paths
> > need strings for low-level OS stuff is a historical and technical
> detail, so
> > no need to drag the entire str type into it if we can provide a
> reasonable
> > helper function (for either the ABC or magic method solution).
>
> I'm not sure I understand what these points are about.


It means we most likely won't add a new method to str in regards to this
proposal.


> Anyway,
> disallowing str or bytes as pathnames will break backwards
> compatibility if done at some point in the future. There's no way
> around that.
>

No one is proposing disallowing str or bytes for a pre-existing API that
supports either. The whole point of this is to make APIs work with strings
and pathlib.


>
> But regarding all this talk of mine about bytes is because it has not
> been completely clear to me if something can break when converting a
> bytes path to str. I did originally propose guaranteeing a str, but I
> am so far only 85% convinced that that does not cause any problems.


Depends on your definition of "problem". If you somehow blindly converted a
bytes object representing a path to a str without knowing its encoding you
will definitely break someone silently (and even os.fsdecode() isn't
fool-proof thanks to multiple encodings on a single file system).


> I
> understand that fsencode(fsdecode(bytes_path)) should always be equal
> to bytes_path. But can some other path operations fail when there are
> surrogates in the strings? And again, not to forget DirEntry, which
> may have a byte string path.
>

At this point no one wants to touch bytes paths. If you need that level of
control because of multiple encodings within a single file system then you
will probably have to stick with managing bytes paths on your own to get
the encoding right.

And just because DirEntry supports bytes doesn't mean that any magic method
it gains has to carry that forward (it can always raise a TypeError if
necessary).


>
> Either way, I suppose os.fspath should accept anything that has
> __fspath__ or is a str or bytes (whether these have the dunder method
> or not).


Maybe. I'm not sure if we will want to down that route of both bytes and
str being supported out of the same function as that gets messy quickly.
The main reason os.scandir() supports it is so it can be a drop-in
replacement for os.listdir(). It really depends on how we choose to
structure the function in terms of just doing the right thing for objects
that follow the protocol or if we want to introduce some required structure
for the resulting path and implement some type guarantees so you have a
better idea of what you will be working with after calling the function.


> Then the options are either to return Union[str, bytes] or to
> always return str. And if the latter does not cause any problems, I
> like it way better, and it seems others would do too.


You don't have to convert byte paths to str, you can simply raise an
exception in the face of them.


> And in that case
> it would probably be time to deprecate bytes paths on posix too (on
> Windows, this is already the case).
>

Can't do that as Stephen Turnbull will tell you. :) At best we can
marginalize the support of bytes-based paths to only low-level APIs exposed
through the os package.

-Brett
___
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

Re: [Python-Dev] Defining a path protocol

[Koos Zevenhoven]

On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon  wrote:
> On Fri, 8 Apr 2016 at 09:39 Ethan Furman  wrote:
>> > 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.
>>
>> That does seem to be a valid point against str.__fspath__.
>
> Yep, and I'm expecting we won't want that at this point. The fact that paths
> need strings for low-level OS stuff is a historical and technical detail, so
> no need to drag the entire str type into it if we can provide a reasonable
> helper function (for either the ABC or magic method solution).

I'm not sure I understand what these points are about. Anyway,
disallowing str or bytes as pathnames will break backwards
compatibility if done at some point in the future. There's no way
around that.

But regarding all this talk of mine about bytes is because it has not
been completely clear to me if something can break when converting a
bytes path to str. I did originally propose guaranteeing a str, but I
am so far only 85% convinced that that does not cause any problems. I
understand that fsencode(fsdecode(bytes_path)) should always be equal
to bytes_path. But can some other path operations fail when there are
surrogates in the strings? And again, not to forget DirEntry, which
may have a byte string path.

Either way, I suppose os.fspath should accept anything that has
__fspath__ or is a str or bytes (whether these have the dunder method
or not). Then the options are either to return Union[str, bytes] or to
always return str. And if the latter does not cause any problems, I
like it way better, and it seems others would do too. And in that case
it would probably be time to deprecate bytes paths on posix too (on
Windows, this is already the case).

But do we know that converting all paths to str does not cause any problems?

-Koos
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Koos Zevenhoven]

On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker  wrote:
> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven  wrote:
>>
>> I'm still thinking a little bit about 'pathname', which to me sounds
>> more like a string than fspath does [1].
>
>
> I like that a lot - or even "__pathstr__" or "__pathstring__"
>
> after all, we're making a big deal out of the fact that a path is *not a
> string*, but rather a string is a *representation* (or serialization) of a
> path.

For me, the point here is the reverse: that any str is not a path, and
that it is misleading to call it *path* when whole point is to make it
*not* a specialized path object but a plain string. I think it's ok to
think of a path as special kind of string. For instance, an URI is
explicitly defined as a *sequence of characters*, and URIs can be
thought of as a more recent, improved and broadened concept than
paths. This is the point of view I took in my recent proposal, but I
don't think it's the only valid way to think about paths "in theory".
I like the "serialization" interpretation as well, but i tend to think
that that string serialization is what is called a path.

Anyway, I don't think these philosophical considerations should
dictate how Python is implemented. But it is always good to also have
a valid theoretical point of view to back up a design decision.

> For the record, this is pretty rare -- and it was announced on -ideas that
> the discussion had started up here -- maybe you missed that post?

If you mean in Ethan's response to my proposal, I noticed that, but
the discussions here had already gone quite far by that time. Even
more so by the time I had time to see what was going on.

I do have to say this is not the first time I felt there was some sort
of hostility towards newcomers on python-ideas. Sure, it might be
partly because those people don't know the culture on the list, but
I'm not sure if that should be used as an excuse.

-Koos
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Ethan Furman]

On 04/08/2016 09:42 AM, Chris Barker wrote:

On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:



While I can only make guesses about what happened, these kinds of

>> things easily make you go from "Hey, maybe I'll be able to do something
>> to improve Python!" to "These people don't seem to want me here or
>> appreciate my efforts.".

Ouch, sorry about that.  Glad to have you on -Dev, too.

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Fri, 8 Apr 2016 at 09:39 Ethan Furman  wrote:

> On 04/08/2016 09:04 AM, Chris Barker wrote:
> > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
>
> >> 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?)
> >
> >> Built-in? (name is dependent on #1 if we add one)
> >
> > os.fspath (alongside os.fsencode and os.fsdecode)
> >
> > [...] 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__() ?
>
> 1) user code may call it
> 2) folks who write libraries are still users ;)
> 3) using __dunder__s directly is usually poor form.
>
> > 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.
>
> That does seem to be a valid point against str.__fspath__.
>

Yep, and I'm expecting we won't want that at this point. The fact that
paths need strings for low-level OS stuff is a historical and technical
detail, so no need to drag the entire str type into it if we can provide a
reasonable helper function (for either the ABC or magic method solution).
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Brett Cannon]

On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven  wrote:

> Nick Coghlan wrote:
> > On 7 April 2016 at 03:26, Brett Cannon  wrote:
> >>
> >> Name: __path__, __fspath__, or something else?
> >
> > __fspath__
> >
>
> I think I might like this dunder name because it does not clutter the
> list of regular methods and attributes, and is perhaps more pythonic.
>
> >> 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, as long as there's a helper function somewhere
>
> As a further minor benefit of it being a method, it may be easier to
> distinguish it from from `__path__`, which is an iterable attribute.
>
> >> 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)
>
> Strong +1 on putting it in os. This should also be implemented in
> DirEntry, instances of which are "yielded" by os.scandir.
>
> Also, you have a strong case regarding naming with the 'fs' prefix. It
> is also easier to read fspath as f-s-path than it is to read ospath as
> o-s-path, because ospath could also be pronounced as a single
> (meaningless?) word.
>
> I'm still thinking a little bit about 'pathname', which to me sounds
> more like a string than fspath does [1]. It would be nice to have the
> string/path distinction especially when pathlib adoption grows larger.
> But who knows, maybe somewhere in the far future, no-one will care
> much about fspath, fsencode, fsdecode or os.path.
>
> >> 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)
> >
> > Makes sense
>
> If added to str, it should also be added to bytes. But will that then
> return str or bytes? See also the next point.
>
> > Expand the C API to have something like PyObject_Path()?
> >
> > PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
> > so it can be done as an alternate constructor, and the C API
> > counterparts of os.fsdecode and os.fsencode are PyUnicode functions
> > (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)
>
> What about DirEntry, which may have a bytes representation? I would
> expect the function return type of os.fspath to be Union[str, bytes],
> unless bytes pathnames are decoded with surrogate escapes.
>
> [1] https://mail.python.org/pipermail/python-ideas/2016-April/039595.html
>
>
> PS. I have been reading this list occasionally on the google groups
> mirror, and I now subscribed to it just to send this. (BTW, I probably
> broke the thread, as I did not have Nick's email in my inbox to reply
> to. Sorry about that.) I'll have to mention that I was surprised, to
> say the least, to find that the pathlib discussion had moved here from
> python-ideas, where I had mentioned I was working on a proposal. Then,
> I also found that the solution discussed here was seemingly an
> improved version of what I had proposed on python-ideas somewhat
> earlier [1], but did not get any reactions to. While I can only make
> guesses about what happened, these kinds of things easily make you go
> from "Hey, maybe I'll be able to do something to improve Python!" to
> "These people don't seem to want me here or appreciate my efforts.".
> Not to accuse anyone in particular; just to let people know. Anyway, I
> somehow got sucked into thinking deeply about pathlib etc. (which I do
> use). Not that I really have much at stake here, except spending
> ridiculous amounts of time thinking about paths, mainly during my
> Easter holidays and after that. I really had a hard time explaining to
> friends and family what the heck I was doing ;).
>

Since I kicked up the discussion here on python-dev, I can explain what
happened.

After the python-ideas threads kicked up I realized I was not using pathlib
in importlib and there were a handful of places it could be supported. But
since pathlib is provisional I didn't want to have to start making the
stdlib support it if we removed the whole module itself. So I simply asked
over here on python-dev what it would take to remove the provisional label
from pathlib. People then pulled over the python-ideas discussion of what
people were upset about in regards to pathlib to help decide what it would
require to remove the provisional label and the conversation forked (I also
assumed Guido and others had muted the discussion over on python-ideas so
it would have been a new thread somewhere regardless). And then when I
realized what had happened I was going to reply to one of your emails on
python-ideas to point out the bifurcation but someone beat me to it.

So the whole thing just 

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Brett Cannon]

On Fri, 8 Apr 2016 at 09:05 Chris Barker  wrote:

> On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan  wrote:
>
>> On 7 April 2016 at 03:26, Brett Cannon  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(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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Chris Barker]

On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven  wrote:

> I'm still thinking a little bit about 'pathname', which to me sounds
> more like a string than fspath does [1].


I like that a lot - or even "__pathstr__" or "__pathstring__"

after all, we're making a big deal out of the fact that a path is *not a
string*, but rather a string is a *representation* (or serialization) of a
path.


> If added to str, it should also be added to bytes.


ouch! not sure I want to go there, though...


>  I'll have to mention that I was surprised, to
> say the least, to find that the pathlib discussion had moved here from
> python-ideas, where I had mentioned I was working on a proposal.

...

>  While I can only make
> guesses about what happened, these kinds of things easily make you go
> from "Hey, maybe I'll be able to do something to improve Python!" to
> "These people don't seem to want me here or appreciate my efforts.".
>

For the record, this is pretty rare -- and it was announced on -ideas that
the discussion had started up here -- maybe you missed that post?

I think in this case, there were ideas over on -ideas, but then it was
decided (by whom, who knows?) that the goal of supporting PAth in the
stdlib was decided upon, so it was time to talk implementation, rather than
ideas -- thus python-dev. In fact, the implementation turned out to be less
straightforward than originally thought, so maybe it should have stayed on
-ideas, but there you go.


> Not to accuse anyone in particular; just to let people know. Anyway, I
> somehow got sucked into thinking deeply about pathlib etc. (which I do
> use). Not that I really have much at stake here, except spending
> ridiculous amounts of time thinking about paths, mainly during my
> Easter holidays and after that. I really had a hard time explaining to
> friends and family what the heck I was doing ;).


speaking only for me - thanks for your contribution -- I'm glad you found
the discussion here.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/08/2016 09:04 AM, Chris Barker wrote:

On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:



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?)


Built-in? (name is dependent on #1 if we add one)


os.fspath (alongside os.fsencode and os.fsdecode)

[...] 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__() ?

1) user code may call it
2) folks who write libraries are still users ;)
3) using __dunder__s directly is usually poor form.


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.


That does seem to be a valid point against str.__fspath__.

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/08/2016 08:41 AM, Brett Cannon wrote:

On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote:

>> Brett previously queried:


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)



What will this do?  Return a Path or a str?  I don't think

>> we need either.


When I brought this up it was to return self.


Okay, thanks.


Chris Angelico and I have been asked by Guido to work together to come
up with a proposal after all the discussions are finished and it will
most likely be a patch to the pathlib PEP.


Cool.  I wasn't looking forward to that part.

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Koos Zevenhoven]

Nick Coghlan wrote:
> On 7 April 2016 at 03:26, Brett Cannon  wrote:
>>
>> Name: __path__, __fspath__, or something else?
>
> __fspath__
>

I think I might like this dunder name because it does not clutter the
list of regular methods and attributes, and is perhaps more pythonic.

>> 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, as long as there's a helper function somewhere

As a further minor benefit of it being a method, it may be easier to
distinguish it from from `__path__`, which is an iterable attribute.

>> 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)

Strong +1 on putting it in os. This should also be implemented in
DirEntry, instances of which are "yielded" by os.scandir.

Also, you have a strong case regarding naming with the 'fs' prefix. It
is also easier to read fspath as f-s-path than it is to read ospath as
o-s-path, because ospath could also be pronounced as a single
(meaningless?) word.

I'm still thinking a little bit about 'pathname', which to me sounds
more like a string than fspath does [1]. It would be nice to have the
string/path distinction especially when pathlib adoption grows larger.
But who knows, maybe somewhere in the far future, no-one will care
much about fspath, fsencode, fsdecode or os.path.

>> 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)
>
> Makes sense

If added to str, it should also be added to bytes. But will that then
return str or bytes? See also the next point.

> Expand the C API to have something like PyObject_Path()?
>
> PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
> so it can be done as an alternate constructor, and the C API
> counterparts of os.fsdecode and os.fsencode are PyUnicode functions
> (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)

What about DirEntry, which may have a bytes representation? I would
expect the function return type of os.fspath to be Union[str, bytes],
unless bytes pathnames are decoded with surrogate escapes.

[1] https://mail.python.org/pipermail/python-ideas/2016-April/039595.html


PS. I have been reading this list occasionally on the google groups
mirror, and I now subscribed to it just to send this. (BTW, I probably
broke the thread, as I did not have Nick's email in my inbox to reply
to. Sorry about that.) I'll have to mention that I was surprised, to
say the least, to find that the pathlib discussion had moved here from
python-ideas, where I had mentioned I was working on a proposal. Then,
I also found that the solution discussed here was seemingly an
improved version of what I had proposed on python-ideas somewhat
earlier [1], but did not get any reactions to. While I can only make
guesses about what happened, these kinds of things easily make you go
from "Hey, maybe I'll be able to do something to improve Python!" to
"These people don't seem to want me here or appreciate my efforts.".
Not to accuse anyone in particular; just to let people know. Anyway, I
somehow got sucked into thinking deeply about pathlib etc. (which I do
use). Not that I really have much at stake here, except spending
ridiculous amounts of time thinking about paths, mainly during my
Easter holidays and after that. I really had a hard time explaining to
friends and family what the heck I was doing ;).
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Chris Barker]

On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan  wrote:

> On 7 April 2016 at 03:26, Brett Cannon  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?


> 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?)

> 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__() ?

> 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.


> 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.

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Fri, 8 Apr 2016 at 08:33 Ethan Furman  wrote:

> On 04/08/2016 02:50 AM, Nick Coghlan wrote:
>
> >> Built-in? (name is dependent on #1 if we add one)
> >
> > os.fspath (alongside os.fsencode and os.fsdecode)
>
> I like this better.
>
>
> >> 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)
> >
> > Makes sense
>
> What will this do?  Return a Path or a str?  I don't think we need either.
>

When I brought this up it was to return self.


>
>
> >> Expand the C API to have something like PyObject_Path()?
> >
> > PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
> > so it can be done as an alternate constructor, and the C API
> > counterparts of os.fsdecode and os.fsencode are PyUnicode functions
> > (specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)
>
> So this will do the same thing as os.fspath() at the C level, yes?
>

Yes.


>
>
> > 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.
> > Plus my specific API suggestions are pretty different from Ethan's :)
>
> *sigh*  Okay
>

Chris Angelico and I have been asked by Guido to work together to come up
with a proposal after all the discussions are finished and it will most
likely be a patch to the pathlib PEP.
___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/08/2016 02:50 AM, Nick Coghlan wrote:


Built-in? (name is dependent on #1 if we add one)


os.fspath (alongside os.fsencode and os.fsdecode)


I like this better.



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)


Makes sense


What will this do?  Return a Path or a str?  I don't think we need either.



Expand the C API to have something like PyObject_Path()?


PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
so it can be done as an alternate constructor, and the C API
counterparts of os.fsdecode and os.fsencode are PyUnicode functions
(specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)


So this will do the same thing as os.fspath() at the C level, yes?



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.
Plus my specific API suggestions are pretty different from Ethan's :)


*sigh*  Okay.

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Victor Stinner]

I like __fspath__ because it looks like os.fsencode() and os.fsdecode().

Please no builtin function, we have enough of them, but make sure that the
__fspath__ is accepted in all functions expecting a filename.

If you consider that a function would make your change simpler, I suggest
to add os.fspath():

if isinstance(obj, str): return obj
try: return obj.__fspath__
except AttributeError: raise TypeError(...)

Victor
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Victor Stinner]

Please write a new PEP.

The topic looks to be discussed since many months by many different people
on different mailing list. A PEP is a good standard to take a decision and
it became clear that a decision must be taken for pathlib.

Victor
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Nick Coghlan]

On 7 April 2016 at 03:26, Brett Cannon  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:
>
> Name: __path__, __fspath__, or something else?

__fspath__

> 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, as long as there's a helper function somewhere

> 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)

> 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)

Makes sense

> Expand the C API to have something like PyObject_Path()?

PyUnicode_FromFSPath, perhaps? The return type is well-defined here,
so it can be done as an alternate constructor, and the C API
counterparts of os.fsdecode and os.fsencode are PyUnicode functions
(specifically PyUnicode_DecodeFSDefault and PyUnicode_EncodeFSDefault)

> 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. :)

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.
Plus my specific API suggestions are pretty different from Ethan's :)

Cheers,
Nick.

-- 
Nick Coghlan   |   ncogh...@gmail.com   |   Brisbane, Australia
___
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

Re: [Python-Dev] Defining a path protocol

[Greg Ewing]

Chris Angelico wrote:

-1 for __os_path__, unless it's reasonable to justify it as "most of
the standard library uses Path objects, but os.path uses strings, so
before you pass a Path to anything in os.path, you call path.ospath()
on it, which calls __os_path__()".


A less roundabout interpretation would be that it returns
the path in a form that is directly acceptable to the OS.

BTW, if __fspath__ is acceptable, __ospath__ (without the
embedded _) should be as well.

--
Greg
___
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

Re: [Python-Dev] Defining a path protocol

[Chris Barker]

On Thu, Apr 7, 2016 at 11:44 AM, Nathaniel Smith  wrote:

> No, __index__ is the protocol for "do a safe coerce to integer". The name
> is misleading, but its use in non-indexing contexts is well established.
> E.g.
>
> " ab" * obj
>
> will return a string with obj.__index__() repetitions.
>
A good argument for Chris A's proposal over on python-ideas to have a
dunder method for "coerce to a lossless string", that could be used for
Path, but also for who knows what else?

As I see it , exactly the same as the __fspath__ idea, except that we'd use
a name that made it clear you might want to use it for other things (and
str would grow that method...)

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Nathaniel Smith]

On Apr 7, 2016 10:00 AM, "Chris Barker"  wrote:
>
> On Thu, Apr 7, 2016 at 12:00 AM, INADA Naoki 
wrote:
>>
>>
>> I feel adding protocol only for path is bit over engineering. So I'm
-0.5 on adding __fspath__.
>>
>> I'm +1 on adding general protocol for *coerce to string* like __index__.
>
>
> isn't __str__ the protocol for "coerce to string" ?
>
> __index__ is a protocol for "coerce to an integer that can be used as an
index", which is like __fspath__ would be "coerce to a string that can be
used as a path"

No, __index__ is the protocol for "do a safe coerce to integer". The name
is misleading, but its use in non-indexing contexts is well established.
E.g.

" ab" * obj

will return a string with obj.__index__() repetitions.

-n
___
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

Re: [Python-Dev] Defining a path protocol

[Chris Barker]

On Thu, Apr 7, 2016 at 4:03 AM, Donald Stufft  wrote:


> It seems like it would be reasonable for pathlib.Path to call fspath on the
> path passed to pathlib.Path.__init__, which would mean that if other
> libraries
> implemented __fspath__ then you could pass their path objects to pathlib
> and
> it would just work


and then any lib that needed a path, could simply wrap Path() around
whatever was passed in.

This is much like using np.array() if you want numpy arrays -- it works
great.

numpy is trickier because they are mutable and can be big, so you don't
want to make a copy if you don't need to -- hence the np.asarray() function
-- but Paths are immutable and far more lightweight.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Chris Barker]

On Thu, Apr 7, 2016 at 12:00 AM, INADA Naoki  wrote:

>
> I feel adding protocol only for path is bit over engineering. So I'm -0.5
> on adding __fspath__.
>
> I'm +1 on adding general protocol for *coerce to string* like __index__.
>

isn't __str__ the protocol for "coerce to string" ?

__index__ is a protocol for "coerce to an integer that can be used as an
index", which is like __fspath__ would be "coerce to a string that can be
used as a path"

the whole point is that __str__ will "work" with virtually anything --
whether it can reasonably be used as a path or not. I'm not sure that's a
problem, but if it is, then that's what this new protocol is trying to
solve, just like __Index__ enforces that only things that are intended to
be used as indexes will work.

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Eric Snow]

On Apr 7, 2016 1:22 AM, "Georg Brandl"  wrote:
>
> On 04/06/2016 07:26 PM, Brett Cannon wrote:
> >  1. Name: __path__, __fspath__, or something else?
>
> __path__ is already taken as a module attribute, so I would avoid it.
> __fspath__ is fine with me, although the more explicit variants are also
> ok.  It's not like you need to read/write it constantly (that's the goal).

+1

I also think that __ospath__ may be more correct since it is an
OS-dependent representation, e.g. slash vs. backslash.

>
> >  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)
>
> An attribute would be somewhat inconsistent with the special-method
lookup rules
> (looked up on the type, not the instance), so a method is probably a
better
> choice.

I was just about to point this out.  The deviation by pickle (lookup on
instance rather than type) has been a source of pain.

>
> >  3. Built-in? (name is dependent on #1 if we add one)
>
> I don't think it warrants a builtin.  I'd place it as a function in
pathlib.

+1

>
> >  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)
>
> +1.

+1

>
> >  5. Expand the C API to have something like PyObject_Path()?
>
> +1 (with _Py_ at first) since you're going to need it in a lot of C
functions.

+1

-eric
___
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

Re: [Python-Dev] Defining a path protocol

[Chris Angelico]

On Thu, Apr 7, 2016 at 9:44 AM, Ethan Furman  wrote:
> Excellent!  Narrowing the field then to:
>
> __fspath__
>
> __os_path__
>
>
> Step right up!  Cast yer votes!

+0.9 for __fspath__; I'd prefer a one-word name, but with __path__ out
of the running (which I agree with), there's no other obvious word.
__fspath__ is a close second.

-1 for __os_path__, unless it's reasonable to justify it as "most of
the standard library uses Path objects, but os.path uses strings, so
before you pass a Path to anything in os.path, you call path.ospath()
on it, which calls __os_path__()". And that seems a bit hairy and
roundabout; what it's _really_ doing is giving you back a string, and
that has little to do with os.path.

ChrisA
___
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

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

On 7 April 2016 at 11:48, Nikolaus Rath  wrote:
> Why is:
>
> path = getattr(obj, '__fspath__') if hasattr(obj, '__fspath__') else obj
>
> better than
>
> path = str(obj) if isinstance(obj, pathlib.Path) else obj

One reason is that the former doesn't need you to import pathlib,
which is good if you need to work with older versions of Python that
don't have pathlib at all (yes, it's just some standard conditional
import boilerplate, but it's additional messiness).

Paul
___
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

Re: [Python-Dev] Defining a path protocol

[Donald Stufft]

> On Apr 7, 2016, at 6:48 AM, Nikolaus Rath  wrote:
> 
> Does anyone anticipate any classes other than those from pathlib to come
> with such a method?


It seems like it would be reasonable for pathlib.Path to call fspath on the
path passed to pathlib.Path.__init__, which would mean that if other libraries
implemented __fspath__ then you could pass their path objects to pathlib and
it would just work (and similarly, if they also called fspath it would enable
interoperation between all of the various path libraries).

-
Donald Stufft
PGP: 0x6E3CBCE93372DCFA // 7C6B 7C5D 5E2B 6356 A926 F04F 6E3C BCE9 3372 DCFA



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
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

Re: [Python-Dev] Defining a path protocol

[Nikolaus Rath]

On Apr 06 2016, Ethan Furman  wrote:
> On 04/06/2016 11:15 PM, Greg Ewing wrote:
>> Chris Barker - NOAA Federal wrote:
>>> But fspath(), if it exists, would call __fspath__ on an arbitrary
>>> object, and create a new string -- not a new Path. That may be
>>> confusing...
>>
>> Maybe something like fspathstr/__fspathstr__ would be better?
>
> As someone already said, we don't need to embed the type in the name.
>
> The point of the __os_path__ protocol is to return the serialized
> version of the Path the object represents.  This would be somewhat
> similar to the various __reduce*__ protocols (which I thought had
> something to do with adding until I learned what they were for).

Does anyone anticipate any classes other than those from pathlib to come
with such a method?

It seems odd to me to introduce a special method (and potentially a
buildin too) if it's only going to be used by a single module.

Why is:

path = getattr(obj, '__fspath__') if hasattr(obj, '__fspath__') else obj

better than

path = str(obj) if isinstance(obj, pathlib.Path) else obj

?

Yes, I know there are other pathlib-like modules out there. But isn't
pathlib meant to replace them?

Best,
Nikolaus

-- 
GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F
Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F

 »Time flies like an arrow, fruit flies like a Banana.«
___
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

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

On 6 April 2016 at 23:46, Brett Cannon  wrote:
> 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.

Ah, that was something I hadn't appreciated, that the builtin would be
3.6+ whereas the protocol would be added to current bugfix releases.

>> 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.

Yeah, the above code assumes that if the builtin isn't available, nor
will the protocol be (see my misunderstanding above).

Paul
___
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

Re: [Python-Dev] Defining a path protocol

[Georg Brandl]

On 04/06/2016 07:26 PM, Brett Cannon 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:

Throwing in my 2 bikesheds here, not having read all subthreads:

>  1. Name: __path__, __fspath__, or something else?

__path__ is already taken as a module attribute, so I would avoid it.
__fspath__ is fine with me, although the more explicit variants are also
ok.  It's not like you need to read/write it constantly (that's the goal).

>  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)

An attribute would be somewhat inconsistent with the special-method lookup rules
(looked up on the type, not the instance), so a method is probably a better
choice.

>  3. Built-in? (name is dependent on #1 if we add one)

I don't think it warrants a builtin.  I'd place it as a function in pathlib.

>  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)

+1.

>  5. Expand the C API to have something like PyObject_Path()?

+1 (with _Py_ at first) since you're going to need it in a lot of C functions.

Georg


___
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

Re: [Python-Dev] Defining a path protocol

[INADA Naoki]

FYI, Ruby's Pathname class doesn't inherit String.

http://ruby-doc.org/stdlib-2.1.0/libdoc/pathname/rdoc/Pathname.html

Ruby has two "convert to string" method.
`.to_s` is like `__str__`.
`.to_str` is like `__index__` but for str.  It is used for implicit
conversion.

File.open accepts any object implements `.to_str`.
___
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

Re: [Python-Dev] Defining a path protocol

[INADA Naoki]

On Thu, Apr 7, 2016 at 2:41 AM, Brett Cannon  wrote:

>
>
> On Wed, 6 Apr 2016 at 10:36 Michel Desmoulin 
> 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
>

https://www.python.org/dev/peps/pep-0357/

> It is not possible to use the nb_int (and __int__ special method)
> for this purpose because that method is used to *coerce* objects
> to integers.

I feel adding protocol only for path is bit over engineering. So I'm -0.5
on adding __fspath__.

I'm +1 on adding general protocol for *coerce to string* like __index__.
+0.5 on inherit from str (and drop byte path support).

-- 
INADA Naoki  
___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 10:26 AM, Brett Cannon wrote:


 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)


Having thought about this some more, it seems we have enough __dunder__ 
attributes that are plain strings that having this one also be a plain 
string should not be a problem:


- __name__
- __module__
- __file__

Since Paths are immutable the __os_path__ attribute isn't going to 
change and doesn't need to be a method.


--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 11:15 PM, Greg Ewing wrote:

Chris Barker - NOAA Federal wrote:

But fspath(), if it exists, would call __fspath__ on an arbitrary
object, and create a new string -- not a new Path. That may be
confusing...


Maybe something like fspathstr/__fspathstr__ would be better?


As someone already said, we don't need to embed the type in the name.

The point of the __os_path__ protocol is to return the serialized 
version of the Path the object represents.  This would be somewhat 
similar to the various __reduce*__ protocols (which I thought had 
something to do with adding until I learned what they were for).


--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Greg Ewing]

Chris Barker - NOAA Federal wrote:

But fspath(), if it exists, would call __fspath__ on an arbitrary
object, and create a new string -- not a new Path. That may be
confusing...


Maybe something like fspathstr/__fspathstr__ would be better?

--
Greg
___
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

Re: [Python-Dev] Defining a path protocol

[Stephen J. Turnbull]

Chris Barker writes:

 > which I suppose we do -- there are already other path implimentaitons out
 > there (though at least some are strings :-) )

Even so, their __fspath__ implementation might return syntactically
canonicalized or realpath paths, rather than whatever is input.  If
cached and the path frequently accessed, the realpath implementation
might be a significant win in some applications.

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 08:50 PM, Chris Barker wrote:
> On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman wrote:

>> It's mostly for the stdlib itself.  I imagine that most libraries
>> would just take what they are given and pass it along to open or
>> os.stat or whatever.
>
> Exactly -- so we really don't need a builtin shortcut.

Hey, we have to program the stdlib too!  No need to make it harder for 
ourselves.



>> It would be more along the lines of pickle -- give me the standard
>> serialized form of this Path, please.
>
> well, give me the standard serialized-path of this arbitrary object,
> yes?

Yes.  :)


>> We are imagining that future libraries that have to muck about with
>> paths will work with Path objects, either by accepting them or
>> converting to them as the (possibly) stringified paths are passed in
>> -- and when necessary those libs can pass either the Path obj or the
>> stringified path to the stdlib.
>
> if that's the case, we don't need the __fspath__ protocol -- then
> reason for the protocol is that we imagine there may be any number of
> third-party objects to represent/work-with paths, that aren't strings
> or stdlib Path objects.

The purpose of the __os_path__ method is two-fold:

- it's presence declares that the object is a path (or convertible
  to one)
- it does the conversion

Since we need it for ourselves there's no reason to prevent others
from taking advantage of it.


>> The point is to allow future programs to work with Path and be able
>> to work with the stdlib as seamlessly and painlessly as possible.
>
> again, we don't need a new protocol for that -- we only need the
> protocol if we want arbitrary future programs to work with arbitrary
> path implementations.

I am certainly not opposed to that.

> which I suppose we do -- there are already other path implimentaitons
> out there (though at least some are strings :-) )

Right.  And I'm already making changes to mine to work with this
new stuff.


> People can totally screw up path variables as strings or Path objects
> too -- I'm having trouble seeing that this is all that more likely --
> after all, python is a dynamic language -- if we wanted full type
> safety, we wouldn't be using python...

Very True.  ;)

> Speaking of which, how is this going to work with the new type
> system?  Do we need an ABC, rather than just a protocol?

I do not know, good question.

> But as long as we get to the stdlib taking Path objects, I'm happy :-)

Excellent!

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Chris Barker]

On Wed, Apr 6, 2016 at 5:57 PM, Ethan Furman  wrote:

> But not a big deal. I think this is pretty much for occasional use by
>
> library authors, so not a big deal what it is named.
>>
>
> It's mostly for the stdlib itself.  I imagine that most libraries would
> just take what they are given and pass it along to open or os.stat or
> whatever.
>

Exactly -- so we really don't need a builtin shortcut.


> Which makes me think: str() calls __str__ on an arbitrary object, and
>> creates a new string object.
>>
>> But fspath(), if it exists, would call __fspath__ on an arbitrary
>> object, and create a new string -- not a new Path. That may be
>> confusing...
>>
>
> It would be more along the lines of pickle -- give me the standard
> serialized form of this Path, please.
>

well, give me the standard serialized-path of this arbitrary object, yes?


> So are we imagining that future libs will be written that only take
>> objects with a __fspath__ method? In which case, do we need to add it
>> to str? In which case, this is all kind of pointless.
>>
>
> We are imagining that future libraries that have to muck about with paths
> will work with Path objects, either by accepting them or converting to them
> as the (possibly) stringified paths are passed in -- and when necessary
> those libs can pass either the Path obj or the stringified path to the
> stdlib.


if that's the case, we don't need the __fspath__ protocol -- the reason for
the protocol is that we imagine there may be any number of third-party
objects to represent/work-with paths, that aren't strings or stdlib Path
objects.

Or maybe all future libs will continue to accept either an str or an
>> object with __fspath__.  In which case, this is pretty pointless, too.
>>
>
> The point is to allow future programs to work with Path and be able to
> work with the stdlib as seamlessly and painlessly as possible.
>

again, we don't need a new protocol for that -- we only need the protocol
if we want arbitrary future programs to work with arbitrary path
implementations.

which I suppose we do -- there are already other path implimentaitons out
there (though at least some are strings :-) )


> I guess what I'm wondering is if we are stuck with str-paths as the
>> lingua-Franca for paths forever. In which case, we should embrace that
>> and just call str() on anything passed in as a path argument.
>>
>
> Nah.  That's inviting trouble and pain, and we're trying to get away from
> that.
>
> Sure, then open(3.5) will give you a file not found error, or maybe
>> create a file with a weird name, but really? Who's going to make that
>> mistake and not figure it out really quickly?
>>
>
> Well, since the 3.5 was actually in my_var, and could have been written
> before it was read, it could easily be days, weeks, or even months --
> probably after the last guy quit, you took the job, the server died, and
> you had to restore from backup -- at which point you'll see all the really,
> really strange file names and wonder what they are.  And of course,
> whatever logic was determining those weird names is now out of sync because
> of the server swap.
>
> And, yeah, I've seen weirder things happen.
>

People can totally screw up path variables as strings or Path objects too
-- I'm having trouble seeing that this is all that more likely -- after
all, python is a dynamic language -- if we wanted full type safety, we
wouldn't be using python...

Speaking of which, how is this going to work with the new type system? Do
we need an ABC, rather than just a protocol?

But as long as we get to the stdlib taking Path objects, I'm happy :-)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(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

Re: [Python-Dev] Defining a path protocol

[Wes Turner]

My mistake.

On Wed, Apr 6, 2016 at 9:40 PM, Ethan Furman  wrote:

> On 04/06/2016 07:24 PM, Wes Turner wrote:
>
>> On Apr 6, 2016 6:31 PM, "Brett Cannon" wrote:
>>
>
> Which suggests perhaps we should have pathlib.fspath() instead of a
>>> built-in.
>>>
>>
>> Would it make sense to instead have pathlib.Path.__init__?
>>
>
> We already have that -- it's what makes a Path.
>
> What we are looking for is a function that accepts a Path or a str and
> returns the Path as a str, or the str passed in.
>
> --
> ~Ethan~
>
>
> ___
> 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/wes.turner%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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 07:24 PM, Wes Turner wrote:

On Apr 6, 2016 6:31 PM, "Brett Cannon" wrote:



Which suggests perhaps we should have pathlib.fspath() instead of a
built-in.


Would it make sense to instead have pathlib.Path.__init__?


We already have that -- it's what makes a Path.

What we are looking for is a function that accepts a Path or a str and 
returns the Path as a str, or the str passed in.


--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Wes Turner]

On Apr 6, 2016 6:31 PM, "Brett Cannon"  wrote:
>
>
>
> On Wed, 6 Apr 2016 at 16:25 Nathaniel Smith  wrote:
>>
>> On Wed, Apr 6, 2016 at 3:46 PM, Brett Cannon  wrote:
>> >
>> >
>> > On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:
>> >>
>> >> 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).
>>
>> For __index__ the "built-in" is:
>>
>> from operator import index
>
>
> Which suggests perhaps we should have pathlib.fspath() instead of a
built-in.

Would it make sense to instead have pathlib.Path.__init__?

>
> ___
> 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/wes.turner%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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 05:43 PM, Chris Barker - NOAA Federal wrote:


__fspath__


+0.1

But not a big deal. I think this is pretty much for occasional use by
library authors, so not a big deal what it is named.


It's mostly for the stdlib itself.  I imagine that most libraries would 
just take what they are given and pass it along to open or os.stat or 
whatever.



Which also means that I don't think we need a built-in function that
calls it, either. How often do people need a stringified-path version
of an arbitrary object?


Not often.


Which makes me think: str() calls __str__ on an arbitrary object, and
creates a new string object.

But fspath(), if it exists, would call __fspath__ on an arbitrary
object, and create a new string -- not a new Path. That may be
confusing...


It would be more along the lines of pickle -- give me the standard 
serialized form of this Path, please.



If we were starting from scratch, I suppose __path__ would return a
Path object -- it would be a protocol one could use to duck-type a
path.


Sure.


But since we have history, we are creating a protocol that conforms to
the existing string-as-path protocol.


Yup.


So are we imagining that future libs will be written that only take
objects with a __fspath__ method? In which case, do we need to add it
to str? In which case, this is all kind of pointless.


We are imagining that future libraries that have to muck about with 
paths will work with Path objects, either by accepting them or 
converting to them as the (possibly) stringified paths are passed in -- 
and when necessary those libs can pass either the Path obj or the 
stringified path to the stdlib.



Or maybe all future libs will continue to accept either an str or an
object with __fspath__.  In which case, this is pretty pointless, too.


The point is to allow future programs to work with Path and be able to 
work with the stdlib as seamlessly and painlessly as possible.



I guess what I'm wondering is if we are stuck with str-paths as the
lingua-Franca for paths forever. In which case, we should embrace that
and just call str() on anything passed in as a path argument.


Nah.  That's inviting trouble and pain, and we're trying to get away 
from that.



Sure, then open(3.5) will give you a file not found error, or maybe
create a file with a weird name, but really? Who's going to make that
mistake and not figure it out really quickly?


Well, since the 3.5 was actually in my_var, and could have been written 
before it was read, it could easily be days, weeks, or even months -- 
probably after the last guy quit, you took the job, the server died, and 
you had to restore from backup -- at which point you'll see all the 
really, really strange file names and wonder what they are.  And of 
course, whatever logic was determining those weird names is now out of 
sync because of the server swap.


And, yeah, I've seen weirder things happen.

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Chris Barker - NOAA Federal]

>> Ah, good point. I think that kills __path__ then as an option.

Darn. I really preferred that. Oh well.

> __fspath__

+0.1

But not a big deal. I think this is pretty much for occasional use by
library authors, so not a big deal what it is named.

Which also means that I don't think we need a built-in function that
calls it, either. How often do people need a stringified-path version
of an arbitrary object?

Which makes me think: str() calls __str__ on an arbitrary object, and
creates a new string object.

But fspath(), if it exists, would call __fspath__ on an arbitrary
object, and create a new string -- not a new Path. That may be
confusing...

If we were starting from scratch, I suppose __path__ would return a
Path object -- it would be a protocol one could use to duck-type a
path.

But since we have history, we are creating a protocol that conforms to
the existing string-as-path protocol.

So are we imagining that future libs will be written that only take
objects with a __fspath__ method? In which case, do we need to add it
to str? In which case, this is all kind of pointless.

Or maybe all future libs will continue to accept either an str or an
object with __fspath__.  In which case, this is pretty pointless, too.

I guess what I'm wondering is if we are stuck with str-paths as the
lingua-Franca for paths forever. In which case, we should embrace that
and just call str() on anything passed in as a path argument.

Sure, then open(3.5) will give you a file not found error, or maybe
create a file with a weird name, but really? Who's going to make that
mistake and not figure it out really quickly?

-CHB
___
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

Re: [Python-Dev] Defining a path protocol

[Glenn Linderman]

On 4/6/2016 4:44 PM, Ethan Furman wrote:

On 04/06/2016 04:27 PM, Brett Cannon wrote:

On Wed, 6 Apr 2016 at 15:54 Gregory P. Smithwrote:


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.


Excellent!  Narrowing the field then to:

__fspath__


-1: not all os names that look like files actually refer to the file 
system: pipes, devices, etc.


__os_path__


+1: the special names are os dependent, so os seems like an appropriate 
prefix.





Step right up!  Cast yer votes!

--
~Ethan~

___
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/v%2Bpython%40g.nevcal.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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 04:27 PM, Brett Cannon wrote:

On Wed, 6 Apr 2016 at 15:54 Gregory P. Smithwrote:


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.


Excellent!  Narrowing the field then to:

__fspath__

__os_path__


Step right up!  Cast yer votes!

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 04:26 PM, Brett Cannon wrote:

On Wed, 6 Apr 2016 at 16:25 Nathaniel Smith wrote:



For __index__ the "built-in" is:

from operator import index


Which suggests perhaps we should have pathlib.fspath() instead of a
built-in.


+1

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 15:54 Gregory P. Smith  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  wrote:
>
>> On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:
>>
>>> On 6 April 2016 at 20:39, Brett Cannon  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 

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 16:25 Nathaniel Smith  wrote:

> On Wed, Apr 6, 2016 at 3:46 PM, Brett Cannon  wrote:
> >
> >
> > On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:
> >>
> >> 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).
>
> For __index__ the "built-in" is:
>
> from operator import index
>

Which suggests perhaps we should have pathlib.fspath() instead of a
built-in.
___
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

Re: [Python-Dev] Defining a path protocol

[Nathaniel Smith]

On Wed, Apr 6, 2016 at 3:54 PM, Gregory P. Smith  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".

To me this observation seems to rule out __path__ as an option: even
if they wouldn't clash in practice, then right now googling __path__
sends you straight to the import system documentation. If we overload
the meaning of the string then it'll make a mess of the
trying-to-figure-out-what-this-__thing__-is experience.

-n

-- 
Nathaniel J. Smith -- https://vorpus.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

Re: [Python-Dev] Defining a path protocol

[Nathaniel Smith]

On Wed, Apr 6, 2016 at 3:46 PM, Brett Cannon  wrote:
>
>
> On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:
>>
>> 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).

For __index__ the "built-in" is:

from operator import index

-n

-- 
Nathaniel J. Smith -- https://vorpus.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

Re: [Python-Dev] Defining a path protocol

[Gregory P. Smith]

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

__gps__



On Wed, Apr 6, 2016 at 3:46 PM Brett Cannon  wrote:

> On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:
>
>> On 6 April 2016 at 20:39, Brett Cannon  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 

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 15:22 Paul Moore  wrote:

> On 6 April 2016 at 20:39, Brett Cannon  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
> 

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

On 6 April 2016 at 20:39, Brett Cannon  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.

>> >> >  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?

So I think we need a builtin.

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. 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'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 :-)

Paul
___
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

Re: [Python-Dev] Defining a path protocol

[Sven R. Kunze]

On 06.04.2016 22:55, Brett Cannon wrote:
On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze > wrote:


Furthermore, we MIGHT later want some URI support, so I don't know
off the top of my head if there's a difference between __fspath__
and __urlpath__ but better separate it now. Later we can re-merge
then if necessary.


There's a difference as a URL represents something different than a 
file system path (URI doesn't necessarily). Plus the serialized format 
would be different, etc.


Sure. URLs and URIs are more than just paths. I would expect __urlpath__ 
to be different than __url__ itself but if that's is a different discussion.


So, __fspath__ for me. :)

Best,
Sven
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 13:54 Sven R. Kunze  wrote:

> On 06.04.2016 22:28, Brett Cannon wrote:
>
> On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze < 
> srku...@mail.de> wrote:
>
>
>> What about
>>
>> __file_path__
>>
>
> Can be a directory as well (and you could argue semantics of file system
> inodes, beginners won't know the subtlety and/or wonder where __dir_path__
> is).
>
>
> Good point.
>
> Well, then __fspath__ for me.
>
>
> I knew instantly what it means especially considering btrfs, ntfs, xfs,
> zfs, etc.
>
> Furthermore, we MIGHT later want some URI support, so I don't know off the
> top of my head if there's a difference between __fspath__ and __urlpath__
> but better separate it now. Later we can re-merge then if necessary.
>

There's a difference as a URL represents something different than a file
system path (URI doesn't necessarily). Plus the serialized format would be
different, etc.
___
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

Re: [Python-Dev] Defining a path protocol

[Sven R. Kunze]

On 06.04.2016 22:28, Brett Cannon wrote:
On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze > wrote:



What about

__file_path__


Can be a directory as well (and you could argue semantics of file 
system inodes, beginners won't know the subtlety and/or wonder where 
__dir_path__ is).


Good point.

Well, then __fspath__ for me.


I knew instantly what it means especially considering btrfs, ntfs, xfs, 
zfs, etc.


Furthermore, we MIGHT later want some URI support, so I don't know off 
the top of my head if there's a difference between __fspath__ and 
__urlpath__ but better separate it now. Later we can re-merge then if 
necessary.



Best,
Sven
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 13:20 Sven R. Kunze  wrote:

> On 06.04.2016 21:02, Alexander Belopolsky wrote:
>
> On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon  wrote:
>
> +1 for __path__, +0 for __fspath__Â (I don't know how widespread the
>> notion that "fs" means "file system" is).
>
>
> Same here.  In the good old days, "fs" stood for a "Font Server."  And
> in even older (and better?) days, FS was a "Field Separator."
>
>
> The future is not the past. ;)
>
>
> What about
>
> __file_path__
>

Can be a directory as well (and you could argue semantics of file system
inodes, beginners won't know the subtlety and/or wonder where __dir_path__
is).
___
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

Re: [Python-Dev] Defining a path protocol

[Sven R. Kunze]

On 06.04.2016 21:02, Alexander Belopolsky wrote:


On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon > wrote:


+1 for __path__, +0 for __fspath__Â (I don't know how widespread
the notion that "fs" means "file system" is).


Same here.  In the good old days, "fs" stood for a "Font Server." 
 And in even older (and better?) days, FS was a "Field Separator."


The future is not the past. ;)


What about

__file_path__

?


Best,
Sven
___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 12:18 PM, Chris Angelico wrote:

On Thu, Apr 7, 2016 at 4:54 AM, Ethan Furman  wrote:

Maybe __os_path__ then?  I would rather be explicit about the type of path
we are dealing with -- who knows if we won't have __url_path__ in the future
(besides Guido, of course ;)



Bikeshedding furiously... I don't like os_path here as it's too
similar to os.path; unless that's deliberate?


Well, it is a Operating System Path.  ;)

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 12:32 PM, Paul Moore wrote:


But I'm not one of the people who disliked using .path, so I'm
probably not best placed to judge. It would be good if someone who
*does* feel strongly could explain why fspath(pathobj) is better than
pathobj.path.


fspath() would be useful because you can pass it a str or a Path and get 
a str back (or an exception if you pass the wrong thing in).


Just like with Path you can pass a str or a Path get a Path back (or an 
exception if ...).


--
--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 12:38 Oleg Broytman  wrote:

> On Wed, Apr 06, 2016 at 11:54:08AM -0700, Ethan Furman 
> wrote:
> > On 04/06/2016 11:32 AM, Brett Cannon wrote:
> > >On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote:
> > >>On 04/06/2016 10:26 AM, Brett Cannon wrote:
> >
> > >>>Now we need clear details. :) Some open questions are:
> > >>>
> > >>> 1. Name: __path__, __fspath__, or something else?
> > >>
> > >>__fspath__
> > >
> > >+1 for __path__, +0 for __fspath__ (I don't know how widespread the
> > >notion that "fs" means "file system" is).
> >
> > Maybe __os_path__ then?  I would rather be explicit about the type of
> path
> > we are dealing with -- who knows if we won't have __url_path__ in the
> future
> > (besides Guido, of course ;)
>
>__pathstr__? __urlstr__?
>

But we didn't call it __indexint__ either. No need to embed the type in the
name.

-Brett


>
> Oleg.
> --
>  Oleg Broytmanhttp://phdru.name/p...@phdru.name
>Programmers don't die, they just GOSUB without RETURN.
> ___
> 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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 12:32 Paul Moore  wrote:

> On 6 April 2016 at 19:32, Brett Cannon  wrote:
> >> > Now we need clear details. :) Some open questions are:
> >> >
> >> >  1. Name: __path__, __fspath__, or something else?
> >>
> >> __fspath__
> >
> > +1 for __path__, +0 for __fspath__ (I don't know how widespread the
> notion
> > that "fs" means "file system" is).
>
> Agreed. But if we have a builtin, it should follow the name of the
> special attribute/method. And I'm not that keen on having a builtin
> with a generic name like 'path'.
>
> >> >  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)
> >>
> >> I would prefer an attribute, but yeah I think dunders are typically
> >> methods, and I don't see this being special enough to not follow that
> >> trend.
> >
> > Depends on what we want to tell 3rd-party libraries to do to support
> pathlib
> > if they are on 3.3 or if they are worried about people using Python
> 3.4.2 or
> > 3.5.1. An attribute still works with `getattr(path, '__path__', path)`.
> But
> > with a method you probably want either `path.__path__() if hasattr(path,
> > '__path__') else path` or `getattr(path, '__path__', lambda: path)()`.
>
> 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).

-Brett


>
> >> >  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.


> 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?

-Brett


>
> But I'm not one of the people who disliked using .path, so I'm
> probably not best placed to judge. It would be good if someone who
> *does* feel strongly could explain why fspath(pathobj) is better than
> pathobj.path.
>


>
> > So:
> >
> >   # Attribute
> >   def fspath(path):
> >   hasattr(path, '__path__'):
> >   return path.__path__
> >   if isinstance(path, str):
> >   return path
> >   raise NotImplementedError  # Or TypeError?
> >
> >   # Method
> >   def fspath(path):
> >   try:
> >   return path.__path__()
> >   except AttributeError:
> >   if isinstance(path, str):
> >   return path
> >   raise TypeError  # Or NotImplementedError?
>
> You could of course use try/except for the attribute case. Or hasattr
> for the method case (where it would avoid masking AttributeError
> exceptions raised within the dunder method call (a possibility if user
> classes implement their own version of the protocol).
>
> Paul
>
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Brett Cannon]

On Wed, 6 Apr 2016 at 12:29 Ryan Gonzalez  wrote:

> --
> 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"  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.
>

But that was removing a custom object, not a function that will implement
whatever idiom we come up with for getting the string representation of a
path.

-Brett


> >
> > 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  wrote:
> >>
> >> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> >> > On 6 April 2016 at 16:53, Nathaniel Smith  wrote:
> >> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan 
> 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

Re: [Python-Dev] Defining a path protocol

[Oleg Broytman]

On Wed, Apr 06, 2016 at 11:54:08AM -0700, Ethan Furman  
wrote:
> On 04/06/2016 11:32 AM, Brett Cannon wrote:
> >On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote:
> >>On 04/06/2016 10:26 AM, Brett Cannon wrote:
> 
> >>>Now we need clear details. :) Some open questions are:
> >>>
> >>> 1. Name: __path__, __fspath__, or something else?
> >>
> >>__fspath__
> >
> >+1 for __path__, +0 for __fspath__ (I don't know how widespread the
> >notion that "fs" means "file system" is).
> 
> Maybe __os_path__ then?  I would rather be explicit about the type of path
> we are dealing with -- who knows if we won't have __url_path__ in the future
> (besides Guido, of course ;)

   __pathstr__? __urlstr__?

Oleg.
-- 
 Oleg Broytmanhttp://phdru.name/p...@phdru.name
   Programmers don't die, they just GOSUB without RETURN.
___
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

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

On 6 April 2016 at 19:32, Brett Cannon  wrote:
>> > Now we need clear details. :) Some open questions are:
>> >
>> >  1. Name: __path__, __fspath__, or something else?
>>
>> __fspath__
>
> +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion
> that "fs" means "file system" is).

Agreed. But if we have a builtin, it should follow the name of the
special attribute/method. And I'm not that keen on having a builtin
with a generic name like 'path'.

>> >  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)
>>
>> I would prefer an attribute, but yeah I think dunders are typically
>> methods, and I don't see this being special enough to not follow that
>> trend.
>
> Depends on what we want to tell 3rd-party libraries to do to support pathlib
> if they are on 3.3 or if they are worried about people using Python 3.4.2 or
> 3.5.1. An attribute still works with `getattr(path, '__path__', path)`. But
> with a method you probably want either `path.__path__() if hasattr(path,
> '__path__') else path` or `getattr(path, '__path__', lambda: path)()`.

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.

>> >  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? 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.

But I'm not one of the people who disliked using .path, so I'm
probably not best placed to judge. It would be good if someone who
*does* feel strongly could explain why fspath(pathobj) is better than
pathobj.path.

> So:
>
>   # Attribute
>   def fspath(path):
>   hasattr(path, '__path__'):
>   return path.__path__
>   if isinstance(path, str):
>   return path
>   raise NotImplementedError  # Or TypeError?
>
>   # Method
>   def fspath(path):
>   try:
>   return path.__path__()
>   except AttributeError:
>   if isinstance(path, str):
>   return path
>   raise TypeError  # Or NotImplementedError?

You could of course use try/except for the attribute case. Or hasattr
for the method case (where it would avoid masking AttributeError
exceptions raised within the dunder method call (a possibility if user
classes implement their own version of the protocol).

Paul
___
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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Ryan Gonzalez]

--
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"  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  wrote:
>>
>> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
>> > On 6 April 2016 at 16:53, Nathaniel Smith  wrote:
>> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan 
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

Re: [Python-Dev] Defining a path protocol

[Chris Angelico]

On Thu, Apr 7, 2016 at 4:54 AM, Ethan Furman  wrote:
> Maybe __os_path__ then?  I would rather be explicit about the type of path
> we are dealing with -- who knows if we won't have __url_path__ in the future
> (besides Guido, of course ;)
>

Bikeshedding furiously... I don't like os_path here as it's too
similar to os.path; unless that's deliberate?

ChrisA
___
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

Re: [Python-Dev] Defining a path protocol

[Alexander Belopolsky]

On Wed, Apr 6, 2016 at 2:32 PM, Brett Cannon  wrote:

> +1 for __path__, +0 for __fspath__ (I don't know how widespread the notion
> that "fs" means "file system" is).


Same here.  In the good old days, "fs" stood for a "Font Server."  And in
even older (and better?) days, FS was a "Field Separator."
___
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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 11:32 AM, Brett Cannon wrote:

On Wed, 6 Apr 2016 at 11:06 Ethan Furman wrote:

On 04/06/2016 10:26 AM, Brett Cannon wrote:



Now we need clear details. :) Some open questions are:

 1. Name: __path__, __fspath__, or something else?


__fspath__


+1 for __path__, +0 for __fspath__ (I don't know how widespread the
notion that "fs" means "file system" is).


Maybe __os_path__ then?  I would rather be explicit about the type of 
path we are dealing with -- who knows if we won't have __url_path__ in 
the future (besides Guido, of course ;)




   def fspath(path):
   try:
   return path.__path__()
   except AttributeError:
   if isinstance(path, str):
   return path
   raise TypeError  # Or NotImplementedError?

Or you can drop the isinstance() check and [...]


If the purpose of fspath() is to return a usable path-as-string then we 
should raise if unable to do it.



If we add str.__fspath__ then the function becomes:

   def fspath(path):
   return path.__fspath__()

Which might be too simplistic for a built-in, but that also means adding
it on str would potentially negate the need for a built-in.


That is an attractive option.

--
~Ethan~
___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 11:06 Ethan Furman  wrote:

> On 04/06/2016 10:26 AM, Brett Cannon 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.
>
> Excellent!  Let's proceed along this path ;) until somebody objects.
>
>
> > Now we need clear details. :) Some open questions are:
> >
> >  1. Name: __path__, __fspath__, or something else?
>
> __fspath__
>

+1 for __path__, +0 for __fspath__ (I don't know how widespread the notion
that "fs" means "file system" is).


>
>
> >  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)
>
> I would prefer an attribute, but yeah I think dunders are typically
> methods, and I don't see this being special enough to not follow that
> trend.
>

Depends on what we want to tell 3rd-party libraries to do to support
pathlib if they are on 3.3 or if they are worried about people using Python
3.4.2 or 3.5.1. An attribute still works with `getattr(path, '__path__',
path)`. But with a method you probably want either `path.__path__() if
hasattr(path, '__path__') else path` or `getattr(path, '__path__', lambda:
path)()`.


>
>
> >  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.
>

So:

  # Attribute
  def fspath(path):
  hasattr(path, '__path__'):
  return path.__path__
  if isinstance(path, str):
  return path
  raise NotImplementedError  # Or TypeError?

  # Method
  def fspath(path):
  try:
  return path.__path__()
  except AttributeError:
  if isinstance(path, str):
  return path
  raise TypeError  # Or NotImplementedError?

Or you can drop the isinstance() check and simply check for the
attribute/method and use it and otherwise return `path` and let the code's
duck-typing of str handle catching an unexpected type for a path. At which
point the built-in becomes whatever idiom we promote for pathlib usage that
pre-dates this protocol.



>
> >  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)
>
> I don't think that's needed.  With Path() and fspath() it's trivial to
> make sure one has what one wants.
>

If we add str.__fspath__ then the function becomes:

  def fspath(path):
  return path.__fspath__()

Which might be too simplistic for a built-in, but that also means adding it
on str would potentially negate the need for a built-in.


>
>
> >  5. Expand the C API to have something like PyObject_Path()?
>
> No opinion.
>

If we add a built-in then I say we add an equivalent function in the C API.

-Brett


>
>
> > 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.
>
> Nice.
>
>
> > 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. :)
>
> If there are no (serious?) objects I don't think a PEP is needed.
>
>
> > 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.
>
> Agreed.
>
> --
> ~Ethan~
>
> ___
> 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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

On 04/06/2016 10:26 AM, Brett Cannon 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.


Excellent!  Let's proceed along this path ;) until somebody objects.



Now we need clear details. :) Some open questions are:

 1. Name: __path__, __fspath__, or something else?


__fspath__



 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)


I would prefer an attribute, but yeah I think dunders are typically 
methods, and I don't see this being special enough to not follow that trend.




 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.




 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)


I don't think that's needed.  With Path() and fspath() it's trivial to 
make sure one has what one wants.




 5. Expand the C API to have something like PyObject_Path()?


No opinion.



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.


Nice.



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. :)


If there are no (serious?) objects I don't think a PEP is needed.



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.


Agreed.

--
~Ethan~

___
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

Re: [Python-Dev] Defining a path protocol

[Brett Cannon]

On Wed, 6 Apr 2016 at 10:36 Michel Desmoulin 
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  > > wrote:
> >
> > On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> > > On 6 April 2016 at 16:53, Nathaniel Smith  > > wrote:
> > >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan  > > 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:
> 

Re: [Python-Dev] Defining a path protocol

[Michel Desmoulin]

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 ?

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  > wrote:
> 
> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> > On 6 April 2016 at 16:53, Nathaniel Smith  > wrote:
> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan  > 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/archive%40mail-archive.com

[Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

[Brett Cannon]

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  wrote:

> On 04/05/2016 11:57 PM, Nick Coghlan wrote:
> > On 6 April 2016 at 16:53, Nathaniel Smith  wrote:
> >> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan 
> 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/archive%40mail-archive.com