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

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

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

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

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

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

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

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

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

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

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

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

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

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?

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

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

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

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

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

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

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

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

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

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

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

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.

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

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

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

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

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

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

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

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

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

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

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)

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

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

Re: [Python-Dev] bugs.python.org email blockage at gmail

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

Re: [Python-Dev] bugs.python.org email blockage at gmail

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 >

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

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

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

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

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

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

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

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

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

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 

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

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

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

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

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

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

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

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,

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

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"

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

On 6 April 2016 at 16:25, Ethan Furman wrote: > On 04/05/2016 10:50 PM, Serhiy Storchaka wrote: >> On 06.04.16 05:44, 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

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

On 04/05/2016 10:00 PM, 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

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

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

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

On 04/05/2016 10:50 PM, Serhiy Storchaka wrote: On 06.04.16 05:44, 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() *

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

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 >

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

On 6 April 2016 at 15:59, Serhiy Storchaka wrote: > On 06.04.16 08:52, Greg Ewing wrote: >> >> Nick Coghlan wrote: >>> >>> The most promising option for that is probably "getattr(path, 'path', >>> path)", >> >> >> Is there something seriously wrong with str(path)? > > What if

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

On 04/05/2016 10:40 PM, Stephen J. Turnbull wrote: Ethan Furman writes: > No, Stephen, that is not what this is about. Wrong Steven. Spelling matters in email too. Yes, it absolutely does. My apologies. -1 Not good enough. I wouldn't do it that often that "ugly" overrides the

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

On 06.04.16 08:52, Greg Ewing wrote: Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", Is there something seriously wrong with str(path)? What if path is None or bytes? ___ Python-Dev mailing list

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

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