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

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.

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

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)

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

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

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

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 #

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

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

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

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"

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

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

Nick Coghlan wrote: The most promising option for that is probably "getattr(path, 'path', path)", Is there something seriously wrong with str(path)? -- Greg ___ Python-Dev mailing list Python-Dev@python.org

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

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() * codecs.open() (et al) * io.* * os.path.* * other os

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

On 6 April 2016 at 15:03, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote: >> Option 4: define a rich-object-to-text path serialisation convention, > > Unfortunately that sounds like a classic "serious programming" > solution

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

Ethan Furman writes: > No, Stephen, that is not what this is about. Wrong Steven. Spelling matters in email too. And he's more worth paying attention to than I am. But I'll have my say anyway. ;-) > This is about the ugliness of code with str(path) this and > str(path) that -1 Not good

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

Chris Angelico writes: > Outside of deliberate tests, we don't create files on our disks > whose names are strings of random bytes; Wishful thinking. First, names made of control characters have often been deliberately used by miscreants to conceal their warez. Second, in some systems it's

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

On 06.04.16 01:41, Brett Cannon wrote: After a rather extensive discussion on python-ideas about pathlib.PurePath not inheriting from str, another point that came up was that the use of pathlib has been rather light. Unfortunately even the stdlib doesn't really use pathlib because it's currently

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

On Tue, Apr 5, 2016 at 7:44 PM, Nick Coghlan wrote: > Option 4: define a rich-object-to-text path serialisation convention, Unfortunately that sounds like a classic "serious programming" solution (objects, abstractions, serialization, all big important words :-). -- --Guido

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

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 >

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

On 6 April 2016 at 13:06, Alexander Walters wrote: > I think the naysayers would be satisfied with an object that... while not > str or bytes or a derived class of either... acted like str when it had to. > Is that possible without deriving from str or bytes? Only if the

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

On 04/05/2016 07:40 PM, Steven D'Aprano wrote: On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote: To me it seems to basically be a question of whether people can be patient during a transition and embrace pathlib over time or if they will simply refuse to add support in libraries

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

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

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

On Wed, Apr 6, 2016 at 12:51 PM, Steven D'Aprano wrote: > On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote: > >> My personal view on the text/bytes debate is that a path is >> fundamentally a human concept, and consists therefore of text. The >> fact that some

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

On 4/5/2016 22:44, Nick Coghlan wrote: Option 4: define a rich-object-to-text path serialisation convention, as paths are not conceptually the same as arbitrary strings Just as a nit to pick, it is perfectly acceptable for hypothetical path objects to raise when someone tries to shoehorn them

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

On Wed, Apr 06, 2016 at 10:02:30AM +1000, Chris Angelico wrote: > My personal view on the text/bytes debate is that a path is > fundamentally a human concept, and consists therefore of text. The > fact that some file systems store (at the low level) bytes and some > store (I think) UTF-16 code

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

On 6 April 2016 at 09:45, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters >> wrote: >>> * pathlib should be improved (specifically by making it

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

I haven't really been following this discussion, but a couple of comments... On Tue, Apr 05, 2016 at 11:47:32PM +, Brett Cannon wrote: > http://www.snarky.ca/why-pathlib-path-doesn-t-inherit-from-str Nice write-up, thanks. [...] > To me it seems to basically be a question of whether

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

On 4/5/2016 7:45 PM, 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

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

On Wed, Apr 6, 2016 at 9:45 AM, Guido van Rossum wrote: > On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: >> On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters >> wrote: >>> * pathlib should be improved (specifically by making it

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

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

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

On Tue, Apr 5, 2016 at 4:13 PM, Chris Angelico wrote: > On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters > wrote: >> * pathlib should be improved (specifically by making it inherit from str) > > I'd like to see this specific change settled on in the

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

On Wed, Apr 6, 2016 at 9:08 AM, Alexander Walters wrote: > * pathlib should be improved (specifically by making it inherit from str) I'd like to see this specific change settled on in the PEP, actually. There are some arguments on both sides, and some hybrid solutions

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

On 4/5/2016 18:55, Guido van Rossum wrote: My last/only comment in the discussion was about there possibly being a dichotomy between people who use Python for scripting and those who use it to write more substantial programs (I'm trying not to judge one group more important than another -- I'm

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

I think the provisional status can be safely lifted now. Even though pathlib hasn't seen that much use, there have been enough reports and discussion since its acception that I think the API has proven it's sane for general use. (as for importlib, pathlib might have too many dependencies for

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

It's been provisional since 3.4. I think if it is still there in 3.6.0 it should be considered no longer provisional. But this may indeed be a test case for the ultimate fate of provisional modules -- should we remove it? I have to admit I got tired of the discussions and muted them all.

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

After a rather extensive discussion on python-ideas about pathlib.PurePath not inheriting from str, another point that came up was that the use of pathlib has been rather light. Unfortunately even the stdlib doesn't really use pathlib because it's currently marked as provisional (or at least