Re: [Python-Dev] Defining a path protocol

Ethan Furman writes: > It means the stuff in place won't change, but the stuff we're > adding now to integrate with Path will only support str (which is > one reason why os.path isn't going to die). I don't think this is a reason for keeping os.path. (Backward compatibility with existing

Re: [Python-Dev] Defining a path protocol

On 04/09/2016 07:32 AM, Nikolaus Rath wrote: On Apr 07 2016, Donald Stufft wrote: On Apr 7, 2016, at 6:48 AM, Nikolaus Rath wrote: Does anyone anticipate any classes other than those from pathlib to come with such a method? It seems like it would be

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

On 04/09/2016 03:51 AM, Koos Zevenhoven wrote: On Sat, Apr 9, 2016 at 10:16 AM, Ethan Furman wrote: 3.5.0 scandir supports bytes: Maybe it's the bytes support in scandir that should be deprecated? (And not bytes support in general, which cannot be done on posix, as I

Re: [Python-Dev] Defining a path protocol

On Apr 07 2016, Donald Stufft wrote: >> On Apr 7, 2016, at 6:48 AM, Nikolaus Rath wrote: >> >> Does anyone anticipate any classes other than those from pathlib to come >> with such a method? > > > It seems like it would be reasonable for pathlib.Path to call

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

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

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

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

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

os.DirEntry doesn't support bytes: os.scandir() only accept str. It's a deliberate choice. I strongly suggest to only support Unicode for filenames in Python 3. So __fspath__ must only return str, or a TypeError must be raised. Victor ___ Python-Dev

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

On 9 April 2016 at 02:02, Koos Zevenhoven wrote: > I'm still thinking a little bit about 'pathname', which to me sounds > more like a string than fspath does [1]. It would be nice to have the > string/path distinction especially when pathlib adoption grows larger. > But who

Re: [Python-Dev] Defining a path protocol

On 04/08/2016 04:05 PM, Koos Zevenhoven wrote: On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote: On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote: At this point no one wants to touch bytes paths. If you need that level of control because of multiple encodings within a single file system

Re: [Python-Dev] Defining a path protocol

On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote: > On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote: > > At this point no one wants to touch bytes paths. If you need that level of > control because of multiple encodings within a single file system then

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote: > On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote: > > On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: > >> > I thought the whole point off all this is that not any old string can >

Re: [Python-Dev] Defining a path protocol

On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote: > On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: >> > I thought the whole point off all this is that not any old string can be >> > a path! (whereas any int can be an index). Unless we go with Chris A's >>

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

On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: > On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote: >> >> I'm still thinking a little bit about 'pathname', which to me sounds >> more like a string than fspath does [1]. > > > I like that a lot -

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

On 04/08/2016 09:42 AM, Chris Barker wrote: On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote: While I can only make guesses about what happened, these kinds of >> things easily make you go from "Hey, maybe I'll be able to do something >> to improve Python!" to "These people don't seem

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote: > On 04/08/2016 09:04 AM, Chris Barker wrote: > > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: > > >> Method, as long as there's a helper function somewhere > > > > what has the helper function got to do with whether it's

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

On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven wrote: > Nick Coghlan wrote: > > On 7 April 2016 at 03:26, Brett Cannon wrote: > >> > >> Name: __path__, __fspath__, or something else? > > > > __fspath__ > > > > I think I might like this dunder name because it

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

On Fri, 8 Apr 2016 at 09:05 Chris Barker wrote: > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: > >> On 7 April 2016 at 03:26, Brett Cannon wrote: >> > > >> > Method or attribute? (changes what kind of one-liner you might use

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

On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote: > I'm still thinking a little bit about 'pathname', which to me sounds > more like a string than fspath does [1]. I like that a lot - or even "__pathstr__" or "__pathstring__" after all, we're making a big deal out of

Re: [Python-Dev] Defining a path protocol

On 04/08/2016 09:04 AM, Chris Barker wrote: On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: Method, as long as there's a helper function somewhere what has the helper function got to do with whether it's a method or attribute (would we call a property an attribute here?) Built-in?

Re: [Python-Dev] Defining a path protocol

On 04/08/2016 08:41 AM, Brett Cannon wrote: On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote: >> Brett previously queried: Add the method/attribute to str? (I assume so, much like __index__() is on int, but I have not seen it explicitly >>> stated so I would rather clarify it) What will

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

Nick Coghlan wrote: > On 7 April 2016 at 03:26, Brett Cannon wrote: >> >> Name: __path__, __fspath__, or something else? > > __fspath__ > I think I might like this dunder name because it does not clutter the list of regular methods and attributes, and is perhaps more pythonic.

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

On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote: > On 7 April 2016 at 03:26, Brett Cannon wrote: > > > Method or attribute? (changes what kind of one-liner you might use in > > libraries, but I think historically all protocols have been methods and >

Re: [Python-Dev] Defining a path protocol

On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote: > On 04/08/2016 02:50 AM, Nick Coghlan wrote: > > >> Built-in? (name is dependent on #1 if we add one) > > > > os.fspath (alongside os.fsencode and os.fsdecode) > > I like this better. > > > >> Add the method/attribute to str?

Re: [Python-Dev] Defining a path protocol

On 04/08/2016 02:50 AM, Nick Coghlan wrote: Built-in? (name is dependent on #1 if we add one) os.fspath (alongside os.fsencode and os.fsdecode) I like this better. Add the method/attribute to str? (I assume so, much like __index__() is on int, but I have not seen it explicitly stated so

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

I like __fspath__ because it looks like os.fsencode() and os.fsdecode(). Please no builtin function, we have enough of them, but make sure that the __fspath__ is accepted in all functions expecting a filename. If you consider that a function would make your change simpler, I suggest to add

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

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

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

On 7 April 2016 at 03:26, Brett Cannon wrote: > WIth Ethan volunteering to do the work to help make a path protocol a thing > -- and I'm willing to help along with propagating this through the stdlib > where I think Serhiy might be interested in helping as well -- and a seeming

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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,

Re: [Python-Dev] Defining a path protocol

> 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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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,

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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~

Re: [Python-Dev] Defining a path protocol

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 >

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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__

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

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

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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"

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

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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__

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Defining a path protocol

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

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

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