Re: [Python-Dev] When should pathlib stop being provisional?

[Nick Coghlan]

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.

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] When should pathlib stop being provisional?

[Wes Turner]

On Apr 6, 2016 1:26 AM, "Chris Angelico"  wrote:
>
> On Wed, Apr 6, 2016 at 3:37 PM, Stephen J. Turnbull 
wrote:
> > Chris Angelico writes:
> >
> >  > Outside of deliberate tests, we don't create files on our disks
> >  > whose names are strings of random bytes;
> >
> > Wishful thinking.  First, names made of control characters have often
> > been deliberately used by miscreants to conceal their warez.  Second,
> > in some systems it's all too easy to create paths with components in
> > different locales (the place I've seen it most frequently is in NFS
> > mounts).  I think that's much less true today, but perhaps that's only
> > because my employer figured out that it was much less pain if system
> > paths were pure ASCII so that it mostly didn't matter what encoding
> > users chose for their subtrees.
>
> Control characters are still characters, though. You can take a
> bytestring consisting of byte values less than 32, decode it as UTF-8,
> and have a series of codepoints to work with.
>
> If your employer has "solved" the problem by restricting system paths
> to ASCII, that's a fine solution for a single system with a single
> ASCII-compatible encoding; a better solution is to mandate UTF-8 as
> the file system encoding, as that's what most people are expecting
> anyway.
>
> > It remains important to be able to handle nearly arbitrary bytestrings
> > in file names as far as I can see.  Please note that 100 million
> > Japanese and 1 billion Chinese by and large still prefer their
> > homegrown encodings (plural!!) to Unicode, while many systems are now
> > defaulting filenames to UTF-8.  There's plenty of room remaining for
> > copying bytestrings to arguments of open and friends.
>
> Why exactly do they prefer these other encodings? Are they
> representing characters that Unicode doesn't contain? If so, we have a
> fundamental problem (no Python program is going to be able to cope
> with these, without a third party library or some stupid mess of local
> code); if not, you can always represent it as Unicode and encode it as
> UTF-8 when it reaches the file system. Re-encoding is something that's
> easy when you treat something as text, and impossible when you treat
> it as bytes.
>
> So far, you're still actually agreeing with me: paths are *text*, but
> sometimes we don't know the encoding (and that's a problem to be
> solved).

re: bytestring, unicode, encodings after e.g. os.path.split / Path.split:

from "[Python-ideas] Type hints for text/binary data in Python 2+3 code"

https://mail.python.org/pipermail/python-ideas/2016-March/038869.html

>> would/will it be possible to
use Typing.Text as a base class for even-more abstract string types

https://mail.python.org/pipermail/python-ideas/2016-March/039016.html

>> * Text.encoding
>> * Text.lang (urn:ietf:rfc:3066)
... forgot to CC:
>> * https://tools.ietf.org/html/rfc5646
  "Tags for Identifying Languages"
  urn:ietf:rfc:5646

is this (Path) a narrower case of string types (#strypes), because after
transformations we want to preserve string metadata like e.g encoding?

I'd vote for
* adding DirEntry.__path__ as a proxy to DirEntry.path
* standardizing on __path__ (over .path)
  * because this operation *is* fundamentally similar to e.g. __str__
* operator.path pathify, pathifize

>
> 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/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] When should pathlib stop being provisional?

[Paul Moore]

On 6 April 2016 at 06:00, Guido van Rossum  wrote:
> On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman  wrote:
>> [...] we can't do:
>>
>> app_root = Path(...)
>> config = app_root/'settings.cfg'
>> with open(config) as blah:
>> # whatever
>>
>> It feels like instead of addressing this basic disconnect, the answer has
>> instead been:  add that to pathlib!  Which works great -- until a user or a
>> library gets this path object and tries to use something from os on it.
>
> I agree that asking for config.open() isn't the right answer here
> (even if it happens to work). But in this example, once 3.5.2 is out,
> the solution would be to use open(config.path), and that will also
> work when passing it to a library. Is it still unacceptable then?

My sense is that this will remain unacceptable to those people who
have a problem here.

The issue is not so much the ugliness of the code (in spite of the
fact that this is what people focus on) but rather the disconnect
between the mental model people have and the reality of the code they
have to write.

The basic idea behind pathlib.Path objects is that they represent a
*path*. And when you call open, you should pass it a path. So (the
argument goes) why should you have to convert the path you have (a
Path object) to pass it to a function (like open) that requires a path
argument?

Making stdlib functions work with Path objects would fix a lot of the
conceptual difficulties here. And it would also mean that (thanks to
duck typing) a lot of 3rd party code would work without change,
further alleviating the issue. But ultimately, there will still be
code that needs changing to be aware of Path objects. The change is
simple enough (patharg = str(patharg), or the getattr('path')
approach) but it's a change in mental model (this time by library
authors) and the benefit of the change is not sufficiently obvious.

Inheriting from str is the commonly-proposed solution, because in
practical terms it works. But it does so by mixing layers of
abstraction in a way that is difficult to explain to someone who
thinks of a "path" as an abstract object rather than as a (text?
byte?) string. Ultimately, all that's happening is that the burden of
keeping the abstractions separate is placed on the design, rather than
being explicit in the code. But while I have no evidence that this is
a problem, it does leave me with a nagging feeling that it "seems
similar to the bytes/text issue".

My feelings:
- I'd *like* to push for the cleaner separation of abstractions that a
"pure" Path object provides.
- It does need library writers (and in particular the stdlib) to "buy
into" the model and make changes to support Path objects
- I don't have a huge problem with using str(p) or p.path as a
workaround during the transition, but that's from the POV of throwaway
scripting. I'm not sure I'd be so happy using the workaround in code
that would need to be supported for a long time.
- I'd rather compromise on principles than abandon the idea of a
stdlib Path object
- In practical terms, inheriting from str is probably fine. At least
evidence from 3rd party path libraries indicates so.

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] When should pathlib stop being provisional?

[Petr Viktorin]

On 04/06/2016 08:53 AM, Nathaniel Smith wrote:
> On Tue, Apr 5, 2016 at 11:29 PM, Nick Coghlan  wrote:
>> On 6 April 2016 at 15:57, Serhiy Storchaka  wrote:
>>> On 06.04.16 05:44, Nick Coghlan wrote:

 The most promising option for that is probably "getattr(path, 'path',
 path)", since the "path" attribute is being added to pathlib, and the
 given idiom can be readily adopted in Python 2/3 compatible code
 (since normal strings and any other object without a "path" attribute
 are passed through unchanged). Alternatively, since it's a protocol,
 double-underscores on the property name may be appropriate (i.e.
 "getattr(path, '__path__', path)")
>>>
>>> This was already discussed. Current conclusion is using the "path"
>>> attribute. See http://bugs.python.org/issue22570 .
>>
>> 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.
> 
> -n
> 

Python was in a similar situation with the .next method on iterators,
which changed to __next__ in Python 3. PEP 3114 (which explains this
change) says:

> Code that nowhere contains an explicit call to a next method can
> nonetheless be silently affected by the presence of such
> a method. Therefore, this PEP proposes that iterators should have
> a __next__ method instead of a next method (with no change in
> semantics).

How well does that apply to path/__path__?

That PEP also introduced the next() builtin. This suggests that a
protocol with __path__/__fspath__ would need a corresponding
path()/fspath() builtin.

___
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] When should pathlib stop being provisional?

[Antoine Pitrou]

Brett Cannon  python.org> writes:
> 
> :) I figured. I was close myself until I decided to be the "not inheriting
from str is a sane decision" camp because people weren't understanding where
the design decision probably came from,
hence http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str

That's a good write-up, thank you. Paths don't have to inherit str
any more than IP addresses or any other thing that happens to be
passed as a string in traditional APIs.

On a concrete point, inheriting str would make the API a horrible,
confusing, dangerous mess missing regular string semantics (concatenation 
with +, for example, or indexing) with path-specific semantics and various
grey areas (should .split() have path semantics or str semantics? what
is the rule and how are people supposed to remember it?).

(of course, for PHP or Javascript programmers it may not sound like a
problem. Let "adding" two IP addresses return the concatenation of
their string representations...)

Regards

Antoine.
___
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] When should pathlib stop being provisional?

[Antoine Pitrou]

Nick Coghlan  gmail.com> writes:
> 
> 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.

That was my preference as well.

> However, I'm also not
> offering to actually *do* the work here, and the casting vote goes to
> the folks pursuing the implementation effort.

Indeed.

Regards

Antoine.


___
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] When should pathlib stop being provisional?

[Antoine Pitrou]

Ethan Furman  stoneleaf.us> writes:
> >
> > Not sure about os.path.*. The purpose of os.path module is manipulating
> > string paths. From the perspective of pathlib it can look lower level.
> 
> The point is that a function that receives a "path" object (whether str 
> or Path) shouldn't have to care: it should be able to call os.path.split 
> on the thing it received and get back a usable answer.

pathlib should already replicate the useful parts of os.path.  That was
the design goal after all.

So this is like saying you want a Python file or socket object to be
accepted by os.read(). In the rare case where you want that, you call the 
.fileno() method explicitly. The equivalent for Path objects is to
lookup the .path attribute explicitly.

Regards

Antoine.


___
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] When should pathlib stop being provisional?

[Steven D'Aprano]

On Tue, Apr 05, 2016 at 11:53:05PM -0700, Nathaniel Smith wrote:

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

It's the down-side of duck-typing. It's all well and good accepting 
anything with a quack method, but not everything is that straight-
forward:

artist.draw()
gunslinger.draw()


I think that file system paths are important enough, and tricky enough, 
to justify their own protocol. I like Nick's suggestion of a special 
dunder method for converting path-like objects into paths, without the 
problems that str(x) has, or the risk of assuming that anything with a 
.path attribute refers to a file system path.

(maze.path, garden.path, career.path perhaps?)


-- 
Steve
___
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] When should pathlib stop being provisional?

[Paul Moore]

On 6 April 2016 at 00:45, Guido van Rossum  wrote:
> This does sound like it's the crucial issue, and it is worth writing
> up clearly the pros and cons. Let's draft those lists in a thread
> (this one's fine) and then add them to the PEP. We can then decide to:
>
> - keep the status quo
> - change PurePath to inherit from str
> - decide it's never going to be settled and kill pathlib.py
>
> (And yes, I'm dead serious about the latter, rather Solomonic option.)

By the way, even if there's no solution that satisfies everyone to the
"inherit from str" question, I'd still be unhappy if pathlib
disappeared from the stdlib. It's useful for quick admin scripts that
don't justify an external dependency. Those typically do quite a bit
of path manipulation, and as such benefit from the improved API of
pathlib over os.path.

+1 on making (and documenting) a final decision on the "inherit from
str" question
-1 on removing pathlib just because that decision might not satisfy everyone

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] bugs.python.org email blockage at gmail

[R. David Murray]

On Wed, 06 Apr 2016 12:21:04 +1000, Nick Coghlan  wrote:
> On 6 April 2016 at 11:27, Terry Reedy  wrote:
> bugs.python.org is currently sending notification emails directly to
> recipients, rather than routing them via the outbound SMTP server on
> mail.python.org.

Correct.

> Reconfiguring it to relay notifications via the main outgoing server
> is the longer term fix, but an initial attempt at enabling that
> resulted in errors in the bugs.python.org mail logs, so David reverted
> to the direct email configuration for the time being.

Specifically, I think we should clean up the issues that are causing
reputation loss (which pretty much means dropping rietveld, although
in theory we could fix rietveld instead if someone wants to finish
Ezio's patch).  And then we need to understand the issue that caused
me to back out the change: something is sending null-Sender emails to
multiple recipients.  We may not need to fix it (mail.python.org rejected
them but they may be useless messages), but we probably should.  I suspect
they are actual bounces, but I don't have the time to investigate further
at this time.

--David
___
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] bugs.python.org email blockage at gmail

[R. David Murray]

On Wed, 06 Apr 2016 12:03:36 +0900, "Stephen J. Turnbull"  
wrote:
> R. David Murray writes:
> 
>  > again.  However, the IPV4 address has a poor reputation, and Verizon
>  > at least appears to be blocking it.  So more work is still needed.
> 
> Don't take Verizon's policy as meaningful.  Tell Verizon customers to
> get another address.  That is the only solution that works for Verizon
> subscribers for very long (based on 15 years of Mailman-Users posts),
> they have never been a high-quality email provider.  Further, Verizon
> (as an email provider) is in the process of dying anyway (they are
> very much alive as the new owner of AOL), so improvements in their
> email practices have a likelihood of zero to the resolution of a C
> float.

Yes, Mark reminded me that Verizon still isn't accepting mail from
mail.python.org, despite multiple contacts from the postmaster team.
So they are pretty much a lost cause and no one should use them for email,
I think.

However, the "poor reputation" comment came from the error message
returned by gmail when it bounced the spam-bounce-reports bugs was trying
to send to Ezio.

--David
___
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] When should pathlib stop being provisional?

[Steven D'Aprano]

On Wed, Apr 06, 2016 at 11:30:32AM +0200, Petr Viktorin wrote:

> Python was in a similar situation with the .next method on iterators,
> which changed to __next__ in Python 3. PEP 3114 (which explains this
> change) says:
> 
> > Code that nowhere contains an explicit call to a next method can
> > nonetheless be silently affected by the presence of such
> > a method. Therefore, this PEP proposes that iterators should have
> > a __next__ method instead of a next method (with no change in
> > semantics).
> 
> How well does that apply to path/__path__?

I think it's potentially the same. Possibly there are fewer existing 
uses of "obj.path" out there which conflict with this use, but there's 
at least one in the std lib: sys.path. 


> That PEP also introduced the next() builtin. This suggests that a
> protocol with __path__/__fspath__ would need a corresponding
> path()/fspath() builtin.

Not necessarily. Take a look at (say) dir(object()) and you'll see a few 
dunders that don't correspond to built-ins:

__reduce__  and __reduce_ex__ are used by pickle;
__sizeof__ is used by sys.getsizeof;
__subclasshook__ is used by the ABC system;

Another example is __trunc__ used by math.trunc().

So any such fspath function should stand on its own as a useful 
feature, not just because there's a dunder method __fspath__.


-- 
Steve
___
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] When should pathlib stop being provisional?

[Nathaniel Smith]

On Apr 6, 2016 07:44, "Steven D'Aprano"  wrote:
>
> On Wed, Apr 06, 2016 at 11:30:32AM +0200, Petr Viktorin wrote:
>
> > Python was in a similar situation with the .next method on iterators,
> > which changed to __next__ in Python 3. PEP 3114 (which explains this
> > change) says:
> >
> > > Code that nowhere contains an explicit call to a next method can
> > > nonetheless be silently affected by the presence of such
> > > a method. Therefore, this PEP proposes that iterators should have
> > > a __next__ method instead of a next method (with no change in
> > > semantics).
> >
> > How well does that apply to path/__path__?
>
> I think it's potentially the same. Possibly there are fewer existing
> uses of "obj.path" out there which conflict with this use, but there's
> at least one in the std lib: sys.path.
>
>
> > That PEP also introduced the next() builtin. This suggests that a
> > protocol with __path__/__fspath__ would need a corresponding
> > path()/fspath() builtin.
>
> Not necessarily. Take a look at (say) dir(object()) and you'll see a few
> dunders that don't correspond to built-ins:
>
> __reduce__  and __reduce_ex__ are used by pickle;
> __sizeof__ is used by sys.getsizeof;
> __subclasshook__ is used by the ABC system;
>
> Another example is __trunc__ used by math.trunc().
>
> So any such fspath function should stand on its own as a useful
> feature, not just because there's a dunder method __fspath__.

An even more precise analogy is provided by __index__, whose semantics are
to provide safe casting to integer (the name is a historical accident), as
opposed to __int__'s tendency to cast things to integer willy-nilly,
including things that really shouldn't be silently accepted as integers.
Basically __index__ is to __int__ as __(fs)path__ would be to __str__.

There's an operator.index but no builtins.index.

-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] When should pathlib stop being provisional?

[Ethan Furman]

On 04/06/2016 02:50 AM, Antoine Pitrou wrote:

Ethan Furman  stoneleaf.us> writes:


Not sure about os.path.*. The purpose of os.path module is manipulating
string paths. From the perspective of pathlib it can look lower level.


The point is that a function that receives a "path" object (whether str
or Path) shouldn't have to care: it should be able to call os.path.split
on the thing it received and get back a usable answer.


pathlib should already replicate the useful parts of os.path.  That was
the design goal after all.


Yes it does, and very well.


So this is like saying you want a Python file or socket object to be
accepted by os.read(). In the rare case where you want that, you call the
.fileno() method explicitly. The equivalent for Path objects is to
lookup the .path attribute explicitly.


Unfortunately for Path objects there is already a well-established 
ecosystem for dealing with paths as strings, and it currently breaks 
when passed a Path path object.  This is a high barrier to entry. 
Having the stdlib support Path objects would lower that barrier 
significantly.


--
~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] When should pathlib stop being provisional?

[Ethan Furman]

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.


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

[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

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

Re: [Python-Dev] When should pathlib stop being provisional?

[Wes Turner]

* +1 for __path__, __fspath__
  (though I don't know what each does)

* why not Text(basestring / bytestring) and pathlib.Path(Text)?
   * are there examples of cases where this cannot be?
  * if not, +1 for subclassing str/Text

  * where are the examples of method collisions between the str
interface and the pathlib.Path interface?
 * str.__div__ is nonsensical
 * pathlib.Path.__div__ is super-useful


On Apr 6, 2016 10:10 AM, "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.
>
> --
> ~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

[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:
> https://mail.python.org/mailman/options/python-dev/brett%40python.org
>
___
Python-Dev mailing list
Python-Dev

Re: [Python-Dev] When should pathlib stop being provisional?

[Brett Cannon]

On Wed, 6 Apr 2016 at 10:41 Wes Turner  wrote:

> * +1 for __path__, __fspath__
>   (though I don't know what each does)
>

Returns a string representing a file system path.


> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
>

See the points about next() vs __next__()


>* are there examples of cases where this cannot be?
>

I don't understand what you think "cannot be".


>   * if not, +1 for subclassing str/Text
>
>   * where are the examples of method collisions between the str
> interface and the pathlib.Path interface?
>

There aren't any and that's partially why some people wanted the str
subclass to begin with.

Please consider this thread a str-subclass-free zone. This line of
discussion is to flesh out the proposal for a path protocol as a proposal
against subclassing str, not to settle the whole discussion outright. If
you want to continue to debate the subclassing-str side of this please use
the other thread.

-Brett


>  * str.__div__ is nonsensical
>  * pathlib.Path.__div__ is super-useful
>
>
> On Apr 6, 2016 10:10 AM, "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.
>>
>> --
>> ~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/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 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 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

[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

[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] When should pathlib stop being provisional?

[Eric Fahlgren]

On Wednesday, April 06, 2016 07:39,  Steven D'Aprano wrote:
> > How well does that apply to path/__path__?
> 
> I think it's potentially the same. Possibly there are fewer existing uses
of
> "obj.path" out there which conflict with this use, but there's at least
one in the
> std lib: sys.path.

Somewhat ironically, also os.

>>> import os.path
>>> getattr(os, "path")


___
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] When should pathlib stop being provisional?

[Barry Warsaw]

On Apr 05, 2016, at 09:29 PM, Ethan Furman wrote:

>We should either remove it or make the rest of the stdlib work with it.
>Currently, pathlib.*Paths are second-class citizens, and working with them is
>not significantly better than working with os.path.* simply because we have
>to cast to str every time we want to deal with any other part of the stdlib.

This.  I've tried to use them in a couple of projects and in many ways pathlib
objects are nice to work with.  But rarely can they be used exclusively.
There are just too many other packages and APIs that use os.path and the two
do not interoperate very well.  That makes practical use of pathlib objects
just too unwieldy for project-wide adoption.

I don't know if inheriting them from str would fix this problem.  I'm +0 on
removing the provisional status of pathlib and in trying to figure out ways
for them to work better with other libraries (both stdlib and 3rd party) that
will continue to be os.path based for the foreseeable future.

Cheers,
-Barry
___
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

[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 (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

[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

[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] When should pathlib stop being provisional?

[Barry Warsaw]

On Apr 06, 2016, at 12:44 PM, Nick Coghlan wrote:

>The next challenge would then be to make a list of APIs to be updated
>for 3.6 to implicitly accept "rich path" objects via the agreed
>convention, with pathlib.PurePath used as a test class:
>
>* open()
>* codecs.open() (et al)
>* io.*
>* os.path.*
>* other os functions
>* shutil.*
>* tempfile.*
>* shelve.*
>* csv.*

Aside from the name of the attribute (though I'm partial to __path__), I think
this would go a long way toward making path objects nicer to work with.  And
right, it doesn't have to be 100% but this would be a big improvement.

Cheers,
-Barry
___
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

[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

[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] When should pathlib stop being provisional?

[Ethan Furman]

On 04/06/2016 02:41 AM, Antoine Pitrou wrote:


On a concrete point, inheriting str would make the API a horrible,
confusing, dangerous mess missing regular string semantics (concatenation
with +, for example, or indexing) with path-specific semantics and various
grey areas (should .split() have path semantics or str semantics? what
is the rule and how are people supposed to remember it?).


While I agree in principle..


(of course, for PHP or Javascript programmers it may not sound like a
problem. Let "adding" two IP addresses return the concatenation of
their string representations...)


Like if had a subnet of '192.168' and a  host of '.11.16' and adding 
them together gave you '192.168.11.16'? (yeah, a bit weak)


Or, more appropriately:  a path of

  '/home/ethan/mystuff' + '_bak'

so I can make a copy?  Actually, that would be

  stuff = pathlib.Path('/home/ethan/mystuff')  # no issue here
  backup_stuff = stuff.with_name(stuff.name + '_bak')  # eww

Sure, you can make the argument that `with_suffix('.bak')` is cleaner, 
but it is not up to the stdlib to micromanage my code.


Oh, and I do not consort with PHP, and only do so with Javascript when 
forced.


--
~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] When should pathlib stop being provisional?

[Ethan Furman]

On 04/05/2016 11:53 PM, 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.


A very good point, thank you.

--
~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 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] When should pathlib stop being provisional?

[Sven R. Kunze]

On 06.04.2016 07:00, Guido van Rossum wrote:

On Tue, Apr 5, 2016 at 9:29 PM, Ethan Furman  wrote:

[...] we can't do:

 app_root = Path(...)
 config = app_root/'settings.cfg'
 with open(config) as blah:
 # whatever

It feels like instead of addressing this basic disconnect, the answer has
instead been:  add that to pathlib!  Which works great -- until a user or a
library gets this path object and tries to use something from os on it.

I agree that asking for config.open() isn't the right answer here
(even if it happens to work).


How come?


But in this example, once 3.5.2 is out,
the solution would be to use open(config.path), and that will also
work when passing it to a library. Is it still unacceptable then?


I think so. Although in this example I would prefer the shorter 
config.open alternative as I am lazy.



I still cannot remember what the concrete issue was why we dropped 
pathlib the same day we gave it a try. It was something really stupid 
and although I hoped to reduce the size of the code, it was less 
readable. But it was not the path->str issue but something more mundane. 
It was something that forced us to use os[.path] as Path didn't provide 
something equivalent. Cannot remember.



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

[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: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] When should pathlib stop being provisional?

[Wes Turner]

On Apr 6, 2016 12:47 PM, "Brett Cannon"  wrote:
>
>
>
> On Wed, 6 Apr 2016 at 10:41 Wes Turner  wrote:
>>
>> * +1 for __path__, __fspath__
>>   (though I don't know what each does)
>
>
> Returns a string representing a file system path.

Why two methods? __uripath__?

(scheme, host (port), path, query, fragment) so, not __uripath__

what would be the difference between __path__ and __fspath__?

>
>>
>> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
>
>
> See the points about next() vs __next__()

Path(b'123') / u'456'

similarly,
Path(b'123') / UTF8 / UTF16

>
>>
>>* are there examples of cases where this cannot be?
>
>
> I don't understand what you think "cannot be".

What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is
distinct from what any given programmer chooses to do with their code.

>
>>
>>   * if not, +1 for subclassing str/Text
>>
>>   * where are the examples of method collisions between the str
interface and the pathlib.Path interface?
>
>
> There aren't any and that's partially why some people wanted the str
subclass to begin with.
>
> Please consider this thread a str-subclass-free zone. This line of
discussion is to flesh out the proposal for a path protocol as a proposal
against subclassing str, not to settle the whole discussion outright. If
you want to continue to debate the subclassing-str side of this please use
the other thread.

this seems to be a sudden, arbitrary distinction.

are these proposals necessarily disjoint?

so,
adding getattr(path, '__path__', path) to stdlib and other code is going to
prevent which edge cases (before  os.path.normpath()* anyway) for which
benefit?

when do I do getattr(path, '__fspath__', path)?

>
> -Brett
>
>>
>>  * str.__div__ is nonsensical
>>  * pathlib.Path.__div__ is super-useful

ah, not .__add__() but .append()

I suppose the request here is for the cases which would be prevented (that
we need to learn to look for)

>>
>>
>>
>> On Apr 6, 2016 10:10 AM, "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.
>>>
>>> --
>>> ~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/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] When should pathlib stop being provisional?

[Ethan Furman]

On 04/06/2016 01:47 PM, Sven R. Kunze wrote:


I still cannot remember what the concrete issue was why we dropped
pathlib the same day we gave it a try. It was something really stupid
and although I hoped to reduce the size of the code, it was less
readable. But it was not the path->str issue but something more mundane.
It was something that forced us to use os[.path] as Path didn't provide
something equivalent. Cannot remember.


I'm willing to guess that if you had been able to just call

  os.whatever(your_path_obj)

it would have been at most a minor annoyance.

--
~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] When should pathlib stop being provisional?

[Brett Cannon]

On Wed, 6 Apr 2016 at 14:03 Wes Turner  wrote:

>
> On Apr 6, 2016 12:47 PM, "Brett Cannon"  wrote:
> >
> >
> >
> > On Wed, 6 Apr 2016 at 10:41 Wes Turner  wrote:
> >>
> >> * +1 for __path__, __fspath__
> >>   (though I don't know what each does)
> >
> >
> > Returns a string representing a file system path.
>
> Why two methods? __uripath__?
>
> (scheme, host (port), path, query, fragment) so, not __uripath__
>
> what would be the difference between __path__ and __fspath__?
>

There is no difference; we're trying to choose a name.


> >
> >>
> >> * why not Text(basestring / bytestring) and pathlib.Path(Text)?
> >
> >
> > See the points about next() vs __next__()
>
> Path(b'123') / u'456'
>
> similarly,
> Path(b'123') / UTF8 / UTF16
>

As other people pointed out on the other thread, while bytes paths do
exist, we don't want to promote them as they are a mess to work with.

-Brett


> >
> >>
> >>* are there examples of cases where this cannot be?
> >
> >
> > I don't understand what you think "cannot be".
>
> What one recommends (path.py(str) / str(pathlib.Path()) + getattr) is
> distinct from what any given programmer chooses to do with their code.
>
> >
> >>
> >>   * if not, +1 for subclassing str/Text
> >>
> >>   * where are the examples of method collisions between the str
> interface and the pathlib.Path interface?
> >
> >
> > There aren't any and that's partially why some people wanted the str
> subclass to begin with.
> >
> > Please consider this thread a str-subclass-free zone. This line of
> discussion is to flesh out the proposal for a path protocol as a proposal
> against subclassing str, not to settle the whole discussion outright. If
> you want to continue to debate the subclassing-str side of this please use
> the other thread.
>
> this seems to be a sudden, arbitrary distinction.
>
> are these proposals necessarily disjoint?
>
> so,
> adding getattr(path, '__path__', path) to stdlib and other code is going
> to prevent which edge cases (before  os.path.normpath()* anyway) for which
> benefit?
>
> when do I do getattr(path, '__fspath__', path)?
>
> >
> > -Brett
> >
> >>
> >>  * str.__div__ is nonsensical
> >>  * pathlib.Path.__div__ is super-useful
>
> ah, not .__add__() but .append()
>
> I suppose the request here is for the cases which would be prevented (that
> we need to learn to look for)
>
> >>
> >>
> >>
> >> On Apr 6, 2016 10:10 AM, "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.
> >>>
> >>> --
> >>> ~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/brett%40python.org
>

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] When should pathlib stop being provisional?

[Sven R. Kunze]

Yeah, sure. But it was more like this on a single line:

   os.missing1(str(our_path.something1)) *** 
os.missing2(str(our_path.something1)) *** 
os.missing1(str(our_path.something1))


And then it started to get messy because you need to work on a single 
long line or you need to open more than one line.


It was a simple thing actually. Like repeating the same calls to pathlib 
just because we need to switch to os.path I will ask my colleague if 
he remembers or if we can recover the code tommorrow...



Best,
Sven


NOTE to myself: getting old, need to write down everything


On 06.04.2016 23:03, Ethan Furman wrote:

On 04/06/2016 01:47 PM, Sven R. Kunze wrote:


I still cannot remember what the concrete issue was why we dropped
pathlib the same day we gave it a try. It was something really stupid
and although I hoped to reduce the size of the code, it was less
readable. But it was not the path->str issue but something more mundane.
It was something that forced us to use os[.path] as Path didn't provide
something equivalent. Cannot remember.


I'm willing to guess that if you had been able to just call

  os.whatever(your_path_obj)

it would have been at most a minor annoyance.

--
~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/srkunze%40mail.de


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

[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
> variables to have the same name as builtins, ID

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 calling
> str(), but yes, that could be something people use.
>

Re: [Python-Dev] When should pathlib stop being provisional?

[Greg Ewing]

Nick Coghlan wrote:

I'd missed the existing precedent in DirEntry.path, so simply taking
that and running with it sounds good to me.


It's not quite the same thing, though. DirEntry.path takes
something that is not a path (a DirEntry instance) and
gives you a path representing it, so the name makes sense.

But a Path instance is already "a path", so Path.path
is weird. Path.str would make more sense.

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

[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

[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

[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

[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 str(p)
>>> return p
>>> except ImportError:
>>> def fsp

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

[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

[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

[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

[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

[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 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]

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

[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&R(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

chris.bar...@noaa.gov
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

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

[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] When should pathlib stop being provisional?

[Raymond Hettinger]

> On Apr 5, 2016, at 3:55 PM, Guido van Rossum  wrote:
> 
> It's been provisional since 3.4. I think if it is still there in 3.6.0
> it should be considered no longer provisional. But this may indeed be
> a test case for the ultimate fate of provisional modules -- should we
> remove it?

I lean slightly towards for removal. 

Having worked through the API when it is first released, I find it to be highly 
forgettable (i.e. I have to re-read the docs each time I've revisited it).

While I haven't seen any uptake in real code, there are occasional questions 
about it on StackOverflow, so we do know that there is at least some interest.  
I'm not sure that it needs to live in the standard library though.


Raymond
___
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] When should pathlib stop being provisional?

[Eric Snow]

On Apr 6, 2016 14:00, "Barry Warsaw"  wrote:
> Aside from the name of the attribute (though I'm partial to __path__),

Ahem, pkg.__path__.

-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

[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

[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

[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