Sorry, I don't have time to read the whole discussion. What is the problem
with adding a __str__ to pathlib?
Victor
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
https://mail.python.or
The discussion has ranged all over, so let me try to sum up:
Name:
__ospath__
Method or attribute?
Method (implementations are of course free to pre-build and/or
cache the value)
Built-in?
no, rather a function in pathlib - ospath()
Add the method/attribute to str?
Not necess
Chris Angelico wrote:
-1 for __os_path__, unless it's reasonable to justify it as "most of
the standard library uses Path objects, but os.path uses strings, so
before you pass a Path to anything in os.path, you call path.ospath()
on it, which calls __os_path__()".
A less roundabout interpretati
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
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 t
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'
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
Le 07/04/2016 16:40, Eric Snow a écrit :
>
> On Apr 6, 2016 11:11 PM, "Raymond Hettinger"
> mailto:raymond.hettin...@gmail.com>> 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).
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
>
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__
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&R(206) 526-6959 voice
7600 Sand Point
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.e
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 interopera
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
>> 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
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:
>>> #
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
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).
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 b
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 s
(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
d
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
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
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 yo
> 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
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
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 t
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
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
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 ?
>>
>
> N
30 matches
Mail list logo
