Re: [Python-Dev] Defining a path protocol

[Chris Barker]

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

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

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

-CHB



-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

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

[Chris Barker]

On Thu, Apr 7, 2016 at 10:02 AM, Antoine Pitrou  wrote:

> >> Having worked through the API when it is first released, I find it to
> > be highly forgettable
>


> This is terribly unspecific as far as criticism goes. "Highly
> forgettable" depends on who you ask.


Exactly -- for my part, I need to look up most of os.path every time I use
it

-CHB

-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

Re: [Python-Dev] Defining a path protocol

[Nathaniel Smith]

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

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

" ab" * obj

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

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

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

[Michel Desmoulin]

Fair enough, I stand corrected for both points.

Le 07/04/2016 18:13, Zachary Ware a écrit :
> On Thu, Apr 7, 2016 at 5:50 AM, Michel Desmoulin
>  wrote:
>> Path objects don't have splitext() or and don't allow  "string" / path.
>> Those are the ones bugging me the most.
> 
 import pathlib
 p = '/some/test' / pathlib.Path('path') / 'file_with.ext'
 p
> PosixPath('/some/test/path/file_with.ext')
 p.parent, p.stem, p.suffix
> (PosixPath('/some/test/path'), 'file_with', '.ext')
> 
> 
___
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] Other pathlib improvements? was: When should pathlib stop being provisional?

[Antoine Pitrou]

Le 07/04/2016 16:40, Eric Snow a écrit :
> 
> On Apr 6, 2016 11:11 PM, "Raymond Hettinger"
> > wrote:
>> 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).
> 
> Agreed, though it's arguably better than argparse, logging, unittest, or
> several other stdlib modules.  To some extent the challenge with those
> is the complexity of the problem space.  Furthermore, the key for any
> sufficiently complex module is that the common-case usage is intuitive
> and simple enough.

This is terribly unspecific as far as criticism goes. "Highly
forgettable" depends on who you ask.  I tend to find unittest and
logging quite useful myself, even if I have to look at the docs from
time to time (and I'm certainly not the only one).

I don't think you'll find an API that doesn't need any learning or
getting used, unless it's simply copying another API.
os.path() is extremely forgettable as well, but after years of getting
used people may feel it's "natural".  Put Python in the hands of a
non-Python programmer, they will find many things bizarre and
uncomfortable compared to their language of choice...

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] Defining a path protocol

[Chris Barker]

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


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


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

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

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

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

Re: [Python-Dev] Defining a path protocol

[Chris Barker]

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

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

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

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

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

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

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

[Chris Barker]

On Thu, Apr 7, 2016 at 3:50 AM, Michel Desmoulin 
wrote:
>
> Path objects don't have splitext()


that is useful -- let's add it. (and others if need be)

-CHB


-- 

Christopher Barker, Ph.D.
Oceanographer

Emergency Response Division
NOAA/NOS/OR(206) 526-6959   voice
7600 Sand Point Way NE   (206) 526-6329   fax
Seattle, WA  98115   (206) 526-6317   main reception

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

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

[Zachary Ware]

On Thu, Apr 7, 2016 at 5:50 AM, Michel Desmoulin
 wrote:
> Path objects don't have splitext() or and don't allow  "string" / path.
> Those are the ones bugging me the most.

>>> import pathlib
>>> p = '/some/test' / pathlib.Path('path') / 'file_with.ext'
>>> p
PosixPath('/some/test/path/file_with.ext')
>>> p.parent, p.stem, p.suffix
(PosixPath('/some/test/path'), 'file_with', '.ext')


-- 
Zach
___
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] Other pathlib improvements? was: When should pathlib stop being provisional?

[Ethan Furman]

On 04/07/2016 08:44 AM, Chris Barker - NOAA Federal wrote:


We could add aliases, but I think it's not such a big deal. I'm
convinced that the largest barrier to adoption has been that it can't
be used with the stdlib. And I think the discussion on Python-ideas
supports that.


Lack of interoperability is a huge issue; using different but similar 
names is still an issue.



That, and py2 compatibility. There is a back port on PyPi, but it
can't be used with the stdlib, either. Not sure what to do about
that--maybe it should inherit from Unicode?


Also huge, and agree it (the backport) should inherit from unicode.

--
~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/07/2016 03:50 AM, Michel Desmoulin wrote:


Path objects don't have splitext() or and don't allow  "string" / path.
Those are the ones bugging me the most.


--> Path('README.md')

--> p = Path('README.md')   # PosixPath('README.md')

--> '/home/ethan' / p  # PosixPath('/home/ethan/README.md')

--> p.splitext()
Traceback (most recent call last):
  File "", line 1, in 
AttributeError: 'PosixPath' object has no attribute 'splitext'

So, yeah, no .splitext()

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

[Chris Barker - NOAA Federal]

>> Personally, the main issue I have with remembering pathlib method
>> names, is the inconsistency with the existing modules.

Was this *really*  not brought up when this was introduced? Oh well.

We could add aliases, but I think it's not such a big deal. I'm
convinced that the largest barrier to adoption has been that it can't
be used with the stdlib. And I think the discussion on Python-ideas
supports that.

That, and py2 compatibility. There is a back port on PyPi, but it
can't be used with the stdlib, either. Not sure what to do about
that--maybe it should inherit from Unicode?

-CHB


> That is one of the things I really dislike.  If the behaviour is the same as 
> the os version, it should have the same name.  I also have no problem with 
> new names that makes more sense so long as an alias exists for the os version 
> (can even be deprecated without removal).
>
>> Would I change the names? I honestly don't know. If os.path was going
>> to disappear, then no - the inconsistency is a short term problem. But
>> even if there's a major switch to pathlib, I expect os.path to remain
>> indefinitely, and that inconsistency will be a wart that we'll have to
>> live with for a long time.
>
> os.path isn't going anywhere.
>
> --
> ~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/chris.barker%40noaa.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] When should pathlib stop being provisional?

[Michel Desmoulin]

Le 06/04/2016 22:47, Sven R. Kunze a écrit :
> 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.

Path objects don't have splitext() or and don't allow  "string" / path.
Those are the ones bugging me the most.

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

[Christophe Bal]

As a simple user, pathlib simplifies playing with paths. A lot of things
are easy to do. For example, Pathlib / "subfile" is so useful.

I also have a subclass of pathlib.Path on github that makes easy seeking
for files and directories.

So keep alive pathlib !
Le 6 avr. 2016 13:06, "Paul Moore"  a écrit :

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/projetmbc%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] Other pathlib improvements? was: When should pathlib stop being provisional?

[Ethan Furman]

On 04/07/2016 08:18 AM, Paul Moore wrote:

On 7 April 2016 at 15:40, Eric Snow  wrote:

On Apr 6, 2016 11:11 PM, "Raymond Hettinger" wrote:



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


Agreed, though it's arguably better than argparse, logging, unittest, or
several other stdlib modules.



Personally, the main issue I have with remembering pathlib method
names, is the inconsistency with the existing modules.


That is one of the things I really dislike.  If the behaviour is the 
same as the os version, it should have the same name.  I also have no 
problem with new names that makes more sense so long as an alias exists 
for the os version (can even be deprecated without removal).



Would I change the names? I honestly don't know. If os.path was going
to disappear, then no - the inconsistency is a short term problem. But
even if there's a major switch to pathlib, I expect os.path to remain
indefinitely, and that inconsistency will be a wart that we'll have to
live with for a long time.


os.path isn't going anywhere.

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

[Paul Moore]

On 7 April 2016 at 15:40, Eric Snow  wrote:
> On Apr 6, 2016 11:11 PM, "Raymond Hettinger" 
> wrote:
>> 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).
>
> Agreed, though it's arguably better than argparse, logging, unittest, or
> several other stdlib modules.  To some extent the challenge with those is
> the complexity of the problem space.  Furthermore, the key for any
> sufficiently complex module is that the common-case usage is intuitive and
> simple enough.  Some stdlib modules do a better job of that than others. :/
> How much would you say that any of that applies to pathlib?  What about
> relative to other similar packages on the cheeseshop?

Personally, the main issue I have with remembering pathlib method
names, is the inconsistency with the existing modules. I always have
to check that it's path.is_dir() compared to os.path.isdir(pathstr).
And it's os.path.dirname(pathstr) vs path.parent. On the other hand,
the consistency between path.parent (for the immediate parent) and
path.parents (for the sequence of parents) is useful, so it's not
clear cut.

There's nothing fundamentally *wrong* with the pathlib method names,
but there's no obvious reason why they needed to change.

I'll get used to them. It's just one more stumbling block that makes
me feel like it's a bit too hard to bother, and I go back to os.path.

Would I change the names? I honestly don't know. If os.path was going
to disappear, then no - the inconsistency is a short term problem. But
even if there's a major switch to pathlib, I expect os.path to remain
indefinitely, and that inconsistency will be a wart that we'll have to
live with for a long time.

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

[Python-Dev] Other pathlib improvements? was: When should pathlib stop being provisional?

[Eric Snow]

On Apr 6, 2016 11:11 PM, "Raymond Hettinger" 
wrote:
> 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).

Agreed, though it's arguably better than argparse, logging, unittest, or
several other stdlib modules.  To some extent the challenge with those is
the complexity of the problem space.  Furthermore, the key for any
sufficiently complex module is that the common-case usage is intuitive and
simple enough.  Some stdlib modules do a better job of that than others.
:/  How much would you say that any of that applies to pathlib?  What about
relative to other similar packages on the cheeseshop?

Regardless, are there any specific improvements you'd recommend while the
module is still provisional?  Are your concerns a matter of structure vs.
naming?  Usability vs. (intuitive) discoverability?

-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

[Python-Dev] pathlib (was: Defining a path protocol)

[Jim J. Jewett]

(1)  I think the "built-in" should instead be a module-level function
in the pathlib.  If you aren't already expecting pathlib paths, then
you're just expecting strings to work anyhow, and a builtin isn't
likely to be helpful.

(2)  I prefer that the function be explicit about the fact that it is
downcasting the representation to a string.  e.g.,
pathlib.path_as_string(my_path)

But if the final result is ospath or fspath or ... I won't fight too
hard, particularly since the output may be a bytestring rather than a
str.

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

Re: [Python-Dev] Defining a path protocol

[Eric Snow]

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

+1

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

>
> >  2. Method or attribute? (changes what kind of one-liner you might use
in
> > libraries, but I think historically all protocols have been methods
and the
> > serialized string representation might be costly to build)
>
> An attribute would be somewhat inconsistent with the special-method
lookup rules
> (looked up on the type, not the instance), so a method is probably a
better
> choice.

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

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

+1

>
> >  4. Add the method/attribute to str? (I assume so, much like
__index__() is on
> > int, but I have not seen it explicitly stated so I would rather
clarify it)
>
> +1.

+1

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

+1

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

Re: [Python-Dev] Defining a path protocol

[Chris Angelico]

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

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

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

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

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

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

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

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

Re: [Python-Dev] Defining a path protocol

[Donald Stufft]

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


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

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Defining a path protocol

[Nikolaus Rath]

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

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

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

Why is:

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

better than

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

?

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

Best,
Nikolaus

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

 »Time flies like an arrow, fruit flies like a Banana.«
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Defining a path protocol

[Paul Moore]

On 6 April 2016 at 23:46, Brett Cannon  wrote:
> str(path) will definitely work, path.__path__ will work if you're running
> the next set of bugfix releases. fspath(path) will only work in Python 3.6
> and newer.

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

>> Maybe a compatibility library could
>> add
>>
>> try:
>> fspath
>> except NameError:
>> try:
>> import pathlib
>> def fspath(p):
>> if isinstance(p, pathlib.Path):
>> return str(p)
>> return p
>> except ImportError:
>> def fspath(p):
>> return p
>>
>> It's messy, like all compatibility code, but it allows code to use
>> fspath(p) in older versions.
>
>
> I would tweak it to check for __fspath__ before it resorted to calling
> str(), but yes, that could be something people use.

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

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

Re: [Python-Dev] Defining a path protocol

[Georg Brandl]

On 04/06/2016 07:26 PM, Brett Cannon wrote:
> WIth Ethan volunteering to do the work to help make a path protocol a thing --
> and I'm willing to help along with propagating this through the stdlib where I
> think Serhiy might be interested in helping as well -- and a seeming consensus
> this is a good idea, it seems like this proposal has a chance of actually 
> coming
> to fruition.
> 
> Now we need clear details. :) Some open questions are:

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

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

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

>  2. Method or attribute? (changes what kind of one-liner you might use in
> libraries, but I think historically all protocols have been methods and 
> the
> serialized string representation might be costly to build)

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

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

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

>  4. Add the method/attribute to str? (I assume so, much like __index__() is on
> int, but I have not seen it explicitly stated so I would rather clarify 
> it)

+1.

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

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

Georg


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

Re: [Python-Dev] Defining a path protocol

[INADA Naoki]

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

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

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

File.open accepts any object implements `.to_str`.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Defining a path protocol

[INADA Naoki]

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

>
>
> On Wed, 6 Apr 2016 at 10:36 Michel Desmoulin 
> wrote:
>
>> Wouldn't be better to generalize that to a "__location__" protocol,
>> which allow to return any kind of location, including path, url or
>> coordinate, ip_address, etc ?
>>
>
> No because all of those things have different semantic meaning. See the
> __index__ PEP for reasons why you would tightly bound protocols instead of
> overloading ones like __int__ for multiple meanings.
>
> -Brett
>

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

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

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

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

-- 
INADA Naoki  
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe: 
https://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

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


 2. Method or attribute? (changes what kind of one-liner you might use
in libraries, but I think historically all protocols have been
methods and the serialized string representation might be costly to
build)


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


- __name__
- __module__
- __file__

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


--
~Ethan~

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

Re: [Python-Dev] Defining a path protocol

[Ethan Furman]

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

Chris Barker - NOAA Federal wrote:

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


Maybe something like fspathstr/__fspathstr__ would be better?


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

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


--
~Ethan~

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

Re: [Python-Dev] Defining a path protocol

[Greg Ewing]

Chris Barker - NOAA Federal wrote:

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


Maybe something like fspathstr/__fspathstr__ would be better?

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