[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

Alexander Walters writes: > If there is headway being made, I do not see it. Filter out everything but the posts by Brett, and see if you still feel that way. (Other people have contributed[1], but that filter has about 20dB better S/N than the whole thread does.) Footnotes: [1] Brett may e

Re: [Python-Dev] pathlib - current status of discussions

On 04/11/2016 10:14 PM, Chris Barker - NOAA Federal wrote: Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Because library XYZ that takes a path and wants to open it shouldn't have to care whether that path is

Re: [Python-Dev] pathlib - current status of discussions

Chris Barker - NOAA Federal wrote: Why in the world do the os.path functions need to work with Path objects? So that applications using path objects can pass them to library code that uses os.path to manipulate them. I'm confused about what a bytes path IS -- is it encoded? It's a sequence

Re: [Python-Dev] thoughts on backporting __wrapped__ to 2.7?

On 6 April 2016 at 15:03, Stephen J. Turnbull wrote: > Robert Collins writes: > > > Sadly that has the ordering bug of assigning __wrapped__ first and appears > > a little unmaintained based on the bug tracker :( > > You can fix two problems with one patch, then! > Not really - taking over a pr

Re: [Python-Dev] pathlib - current status of discussions

Donald Stufft writes: > I think yes and yes [__fspath__ and fspath should be allowed to > handle bytes, otherwise] it seems like making it needlessly harder > to deal with a bytes path It's not needless. This kind of polymorphism makes it hard to review code locally. Once bytes get a foothol

Re: [Python-Dev] pathlib - current status of discussions

> with the > rationale being the one someone mentioned regarding ease-of-use in > os.path. > > Consider os.path.join: Why in the world do the os.path functions need to work with Path objects? ( and other conforming objects) Thus all started with the goal of using Path objects in the stdlib, but

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 13:45, Nick Coghlan wrote: > Consider os.path.join: with a permissive os.fspath, the necessary > update should just be to introduce "map(os.fspath, args)" (or its C > equivalent), and then continue with the existing bytes vs str handling > logic. That does remind me: once a pa

Re: [Python-Dev] pathlib - current status of discussions

On 12 April 2016 at 07:58, Ethan Furman wrote: > Sticking points: > --- > > Do we allow bytes to be returned from os.fspath()? If yes, then do we allow > bytes from __fspath__()? I've come around to the point of view that allowing both str and bytes-like objects to pass through uncha

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 8:43 AM, Jon Ribbens wrote: > On Tue, Apr 12, 2016 at 03:02:54AM +1000, Chris Angelico wrote: >> It all depends on how much functionality you want. If all you need is >> a numeric expression evaluator, that's not too hard - disallow all >> forms of attribute access, etc, an

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 01:08:36PM +1200, Greg Ewing wrote: > Jon Ribbens wrote: > >So far it looks like blocking "_*" and the frame object attributes > >appears to be sufficient. > > Even if your sandbox as it currently exists is secure, it's > only an extremely restricted subset. I'm not sure w

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 8:08 PM, Greg Ewing wrote: > Jon Ribbens wrote: > >> So far it looks like blocking "_*" and the frame object attributes >> appears to be sufficient. >> > > Even if your sandbox as it currently exists is secure, it's > only an extremely restricted subset. You seem to be ass

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Jon Ribbens wrote: So far it looks like blocking "_*" and the frame object attributes appears to be sufficient. Even if your sandbox as it currently exists is secure, it's only an extremely restricted subset. You seem to be assuming that if your technique works so far, then it can be extended t

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman wrote: # after new protocol with bytes/str support def zingar(a_path): a_path = fspath(a_path) if not isinstance(a_path, (bytes,str)): raise TypeError('bytes or str required') ... I think that one would be just def zingar(a_path): a_path =

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Sorry, I've forgot to use "Reply All". On Tue, Apr 12, 2016 at 9:49 AM, INADA Naoki wrote: > IHMO it's safer to get an encoding error rather than no error when you >> concatenate two byte strings encoded to two different encodings (mojibake). >> >> print(os.fspath(obj)) will more likely do what

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 01:42 PM, Victor Stinner wrote: With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a bytes path to str using os.fsdecode(). Does this mean that os.fsdecode() is simply a wrapper that sets the errors to the sur

Re: [Python-Dev] Summary of the pathlib discussion (Re: Maybe, just maybe, pathlib doesn't belong.)

On Tue, Apr 12, 2016 at 7:55 AM, Brett Cannon wrote: > That's pretty much it unless Chris or Ethan disagree. So I think pathlib is > far from being as dead as a parrot. ;) That looks like an accurate summary! ChrisA ___ Python-Dev mailing list Python-D

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Le 11 avr. 2016 11:11 PM, "Ethan Furman" a écrit : > So my concern in such a case is what happens if we pass this SE string somewhere else: a UTF-8 file, or over a socket, or into a database? Does this have issues that we wouldn't face if we just used bytes? "SE string" are returned by os.listdir

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 17:15, Ethan Furman wrote: > So we're trying to make option 2 work before falling back to option 1. > > If you have a way to make pathlib work with the stdlib that doesn't > involve "fixing" os and os.path, now is the time to speak up. Fully general re-dispatch from argu

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 03:02:54AM +1000, Chris Angelico wrote: > On Tue, Apr 12, 2016 at 2:53 AM, Jon Ribbens > wrote: > > On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: > >> However, it's not at all clear (to me at least) what you *are* trying > >> to do. > > > > I'm trying to see t

Re: [Python-Dev] pathlib - current status of discussions

> On Apr 11, 2016, at 5:58 PM, Ethan Furman wrote: > > name: > > > We are down to two choices: > > - __fspath__, or > - __fspathname__ > > The final choice I suspect will be affected by the choice to allow (or not) > bytes. +1 on __fspath__, -0 on __fspathname__ > > > > add a Path

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

You seem to be defining a (restricted subset of an existing) language; which will need version strings and ABI tags for compatibility purposes: * Build Tags (for Python variants): * https :// www.python.org

Re: [Python-Dev] Summary of the pathlib discussion (Re: Maybe, just maybe, pathlib doesn't belong.)

On 04/11/2016 02:55 PM, Brett Cannon wrote: That's pretty much it unless Chris or Ethan disagree. So I think pathlib is far from being as dead as a parrot. ;) That's nearly exactly what I wrote in my summary. :) So, yes, we are nearly there! -- ~Ethan~ __

[Python-Dev] pathlib - current status of discussions

name: We are down to two choices: - __fspath__, or - __fspathname__ The final choice I suspect will be affected by the choice to allow (or not) bytes. method or attribute: --- method built-in: Almost - we'll put it in the os module add to str: --

[Python-Dev] Summary of the pathlib discussion (Re: Maybe, just maybe, pathlib doesn't belong.)

On Mon, 11 Apr 2016 at 14:42 Ben Finney wrote: > Alexander Walters writes: > > > That is great news. I just couldn't see it myself in the threads > > Agreed. A summary posting, from someone who has a good handle on the > issue and outcome, would be very helpful. > - Guido has put Chris Ang

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:15, Ethan Furman wrote: We've pretty decided that we have two options: 1. remove pathlib 2. make the stdlib work with pathlib So we're trying to make option 2 work before falling back to option 1. If you have a way to make pathlib work with the stdlib that doesn't involve "fi

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 14:11 Ethan Furman wrote: > On 04/11/2016 01:42 PM, Victor Stinner wrote: > > 2016-04-11 21:00 GMT+02:00 Brett Cannon: > > >> I'm -0 on allowing __fspath__ to return bytes, but we can see what > others > >> think. > > > > With the PEP 383, a bytes filename can be stored as

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

Alexander Walters writes: > That is great news. I just couldn't see it myself in the threads Agreed. A summary posting, from someone who has a good handle on the issue and outcome, would be very helpful. -- \ “Firmness in decision is often merely a form of stupidity. It | `\i

Re: [Python-Dev] pathlib+os/shutil feedback

On Mon, 11 Apr 2016 at 13:40 Sven R. Kunze wrote: > On 10.04.2016 16:51, Paul Moore wrote: > > On 10 April 2016 at 15:07, Sven R. Kunze wrote: > >> If there's some agreement to change things with respect to those 5 > points, I > >> am willing to put some time into it. > > In broad terms I agree

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:05, Random832 wrote: On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 23:08, Random832 wrote: On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: PS: The only way out that I can imagine is to fix pathlib. I am not in favor of fixing functions of "os" and "os.path" to except "path" objects; Why not? It occurred to me after pondering over Paul's co

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

This stance was probably already argued in the threads in question. This thread is more of a health-check. As an observer, it did not look like any headway was being made, and I suggested the solimaic solution. It has been pointed out to me that headway IS being made and they are close to a s

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 04/11/2016 02:04 PM, Sven R. Kunze wrote: On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not, we should consider either dropping the matter o

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 17:04, Sven R. Kunze wrote: > PS: The only way out that I can imagine is to fix pathlib. I am not in > favor of fixing functions of "os" and "os.path" to except "path" > objects; Why not? ___ Python-Dev mailing list Python-Dev@

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:55, Alexander Walters wrote: Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of them? If not, we should consider either dropping the matter or dropping the module. Right now, I don't se

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 01:42 PM, Victor Stinner wrote: 2016-04-11 21:00 GMT+02:00 Brett Cannon: I'm -0 on allowing __fspath__ to return bytes, but we can see what others think. With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a b

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On Mon, Apr 11, 2016, at 16:48, Sven R. Kunze wrote: > On 11.04.2016 22:33, Alexander Walters wrote: > > If there is headway being made, I do not see it. > > Funny that you brought it up. I was about posting something myself. I > cannot agree completely. But starting with a comment from Paul, I

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

That is great news. I just couldn't see it myself in the threads On 4/11/2016 16:51, Ethan Furman wrote: If there is headway being made, I do not see it. It's being made, and I dare say we are close to the end. ___ Python-Dev mailing list Python-

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

If i had my druthers, this thread would be kept to either: "Shut up alex, we are really close to figuring this out" or "Ok, maybe you have a point." Every conceivable way to fix pathlib have already been argued. Are any of them worth doing? Can we get consensus enough to implement one of t

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 04/11/2016 01:33 PM, Alexander Walters wrote: In reviewing the ongoing arguments about how to make pathlib better, there have been circular arguments about if it is even broken, if it should support bytes, if there should be a path protocol that all functions that touch the filesystem should

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

On 11.04.2016 22:33, Alexander Walters wrote: If there is headway being made, I do not see it. Funny that you brought it up. I was about posting something myself. I cannot agree completely. But starting with a comment from Paul, I realized that pathlib is something different than a string. Af

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

2016-04-11 21:00 GMT+02:00 Brett Cannon : > I'm -0 on allowing __fspath__ to return bytes, but we can see what others > think. With the PEP 383, a bytes filename can be stored as str using the surrogateescape error handler. So DirEntry can convert a bytes path to str using os.fsdecode(). A "byte

Re: [Python-Dev] Maybe, just maybe, pathlib doesn't belong.

Neverending email chains aside, as a mere user, I like pathlib even as it is today and like the convenience of it being in the stdlib. (And would like it even more if the stdlib played nicely with it) I would be disappointed if it were taken out. (It's one of the few recent additions that I find us

Re: [Python-Dev] pathlib+os/shutil feedback

On 10.04.2016 16:51, Paul Moore wrote: On 10 April 2016 at 15:07, Sven R. Kunze wrote: If there's some agreement to change things with respect to those 5 points, I am willing to put some time into it. In broad terms I agree with these points. Thanks for doing the research. It would certainly b

[Python-Dev] Maybe, just maybe, pathlib doesn't belong.

In reviewing the ongoing arguments about how to make pathlib better, there have been circular arguments about if it is even broken, if it should support bytes, if there should be a path protocol that all functions that touch the filesystem should use, if that protocol should support bytes, how

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 12:00 PM, Brett Cannon wrote: On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote: I would write the above as: def fspath(path, *, allow_bytes=False): You get type consistency from so.fspath(), not the protocol, though. Well, since the protocol is also a function, we could p

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 11:28 Ethan Furman wrote: > On 04/11/2016 10:36 AM, Brett Cannon wrote: > > On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > > >> I'm not saying that bytes paths are common -- and if this was a > >> brand-new feature I wouldn't be pushing for it so hard; however, bytes >

Re: [Python-Dev] PEP 506 secrets module

On 04/11/2016 11:35 AM, Guido van Rossum wrote: Most excellent! PEP 506 is hereby approved. Congrats again. Congratulations, Steven! -- ~Ethan~ ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Un

Re: [Python-Dev] PEP 506 secrets module

Most excellent! PEP 506 is hereby approved. Congrats again. On Mon, Apr 11, 2016 at 10:50 AM, Steven D'Aprano wrote: > On Sun, Apr 10, 2016 at 11:43:08AM -0700, Guido van Rossum wrote: >> Hi Steven, >> >> No probIem with the delay -- it's still before 3.6.0. I do think it's >> just about a record

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #25910: Fixed more links in the docs.

On 11.04.16 17:41, Tim Golden wrote: On 11/04/2016 15:38, serhiy.storchaka wrote: - `__. + `__. Is there any intended irony in our link to openssl not being via

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 10:36 AM, Brett Cannon wrote: On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: I'm not saying that bytes paths are common -- and if this was a brand-new feature I wouldn't be pushing for it so hard; however, bytes paths are already supported and it seems to me to be much less of

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016, at 13:36, Brett Cannon wrote: > How about we take something from the "explicit is better than implicit" > playbook and add a keyword argument to os.fspath() to allow bytes to pass > through? Except, we already know how to convert a bytes-path into a str (and vice versa) with

Re: [Python-Dev] PEP 506 secrets module

On Sun, Apr 10, 2016 at 11:43:08AM -0700, Guido van Rossum wrote: > Hi Steven, > > No probIem with the delay -- it's still before 3.6.0. I do think it's > just about a record gap in the PEP review process. :-) > > I will approve the PEP as soon as you've updated the two function > names in the PE

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman stoneleaf.us> writes: > > On 04/11/2016 07:56 AM, Antoine Pitrou wrote: > > >> 2) pathlib.Path accepts bytes -- > > > > Does it? Or are you proposing such a change? > > It used to (I posted a couple examples from 3.5.0). I finally rebuilt > with the latest and it no longer does.

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, 11 Apr 2016 at 10:13 Ethan Furman wrote: > On 04/11/2016 09:32 AM, Zachary Ware wrote: > > On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > > >> If those examples are anywhere close to accurate, an fspath protocol > that > >> supported both bytes and str seems a lot easier to work

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

> On Apr 11, 2016, at 1:12 PM, Ethan Furman wrote: > > Asked another way, what are we gaining by disallowing bytes in this new way > of getting paths versus the pain caused when bytes are needed and/or accepted? It seems fine to me to allow __fspath__ to return bytes as well as str. The only

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 09:32 AM, Zachary Ware wrote: On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: If those examples are anywhere close to accurate, an fspath protocol that supported both bytes and str seems a lot easier to work with. But why are you working with bytes paths in the first plac

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Tue, Apr 12, 2016 at 2:53 AM, Jon Ribbens wrote: > On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: >> However, it's not at all clear (to me at least) what you *are* trying >> to do. > > I'm trying to see to what extent we can use ast node inspection to > remedy the failures of prior

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 04:04:21PM +0100, Paul Moore wrote: > However, it's not at all clear (to me at least) what you *are* trying > to do. I'm trying to see to what extent we can use ast node inspection to remedy the failures of prior attempts at Python sandboxing. Is there *any* extent to which

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 08:35:11AM -0700, Nikolaus Rath wrote: > On Apr 11 2016, Jon Ribbens wrote: > >> What I see is that you asked to break your sandbox, and less than 1 > >> hour later, a first vulnerability was found (exec called with two > >> parameters). A few hours later, a second vulnerab

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016 at 11:18 AM, Ethan Furman wrote: > If those examples are anywhere close to accurate, an fspath protocol that > supported both bytes and str seems a lot easier to work with. But why are you working with bytes paths in the first place? Where did you get them from, and why could

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

Steven D'Aprano: > although I must admit I don't understand why the entire OS is effected. A consequence of memory overcommit, I'd wager. The crasher code not only allocates vast swathes of memory, but accesses it as well, which is bad news for Linux with overcommit enabled. When the OS runs ou

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/10/2016 11:27 PM, Nick Coghlan wrote: On 11 April 2016 at 02:16, Ethan Furman wrote: DirEntry can still get the check, it can just throw TypeError when it represents a binary path (that's one of the advantages of using a method-based protocol - exceptions on method calls are more accept

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 9:04 PM, Isaac Morland wrote: > But I would not use for security purposes a Python sandbox that was not > formally verified to be correct and unbreakable. Of course in order for > this to be possible, there first has to be a formal semantics for Python. > Has anybody made

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, 11 Apr 2016, Victor Stinner wrote: 2016-04-10 18:43 GMT+02:00 Jon Ribbens : That's the opposite of my approach though - I'm starting small and adding things, not starting with everything and removing stuff. Even if what we end up with is an extremely restricted subset of Python, there

[Python-Dev] tp_new selection regression in the 2.7 branch

Hi, changeset https://hg.python.org/cpython/rev/e7062dd9085e in the 2.7 branch changes how tp_new is assigned, and causes regressions with multiple inheritance from extension classes. http://bugs.python.org/issue25731#msg262922 has a fairly simple reproducer using cython. The __base__ attribute i

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Apr 11 2016, Jon Ribbens wrote: >> What I see is that you asked to break your sandbox, and less than 1 >> hour later, a first vulnerability was found (exec called with two >> parameters). A few hours later, a second vulnerability was found >> (async generator and cr_frame). > > The former was j

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On 04/11/2016 07:56 AM, Antoine Pitrou wrote: 2) pathlib.Path accepts bytes -- Does it? Or are you proposing such a change? It used to (I posted a couple examples from 3.5.0). I finally rebuilt with the latest and it no longer does. -- ~Ethan~

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11 April 2016 at 15:46, Jon Ribbens wrote: > It's trying to alter > the global Python environment so that arbitrary code can be executed, > whereas I am not even trying to allow execution of arbitrary code and > am not altering the global environment. However, it's not at all clear (to me at l

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

On Mon, Apr 11, 2016 at 9:27 AM, Nick Coghlan wrote: > On 11 April 2016 at 02:16, Ethan Furman wrote: >> >> I guess I don't see the point of this. Either DirEntry's [1] only get >> partial support (which is only marginally better than the no support pathlib >> currently has), or stdlib code will

Re: [Python-Dev] Pathlib enhancements - acceptable inputs and outputs for __fspath__ and os.fspath()

Ethan Furman stoneleaf.us> writes: > > I also think the more explicit name helps answer some of the type > > signature questions that have arisen: > > > > 1. Does os.fspathname return rich Path objects? No, it returns names > > as str objects > > 2. Will file descriptors pass through os.fspa

Re: [Python-Dev] Pathlib enhancments - method name only

Ethan Furman stoneleaf.us> writes: > > That's a decent point. > > So the plausible choices are, I think: > > - __fspath__ # File System Path -- possible confusion with Path This would have my preference. Regards Antoine. ___ Python-Dev mailing l

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 11:40:05AM +0200, Victor Stinner wrote: > 2016-04-10 18:43 GMT+02:00 Jon Ribbens : > > That's the opposite of my approach though - I'm starting small and > > adding things, not starting with everything and removing stuff. Even > > if what we end up with is an extremely restr

Re: [Python-Dev] [Python-checkins] cpython (2.7): Issue #25910: Fixed more links in the docs.

On 11/04/2016 15:38, serhiy.storchaka wrote: > - `__. > + `__. Is there any intended irony in our link to openssl not being via https? :) TJG

Re: [Python-Dev] Pathlib enhancments - method name only

On Sat, Apr 9, 2016 at 10:48 AM, Nick Coghlan wrote: > On 9 April 2016 at 04:25, Brett Cannon wrote: >> On Fri, 8 Apr 2016 at 11:13 Ethan Furman wrote: >>> On 04/08/2016 10:46 AM, Koos Zevenhoven wrote: >>> > On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote: >>> >> On Fri, Apr 8, 2016 at 9:

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

2016-04-10 18:43 GMT+02:00 Jon Ribbens : > On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: >>Please don't loose time trying yet another sandbox inside CPython. It's >>just a waste of time. It's broken by design. >> >>Please read my email about my attempt (pysandbox): >>

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On Mon, Apr 11, 2016 at 08:06:34AM +0200, Oleg Broytman wrote: > On Mon, Apr 11, 2016 at 12:42:47AM -0500, Wes Turner > wrote: > > On Sun, Apr 10, 2016 at 10:50 PM, Oleg Broytman wrote: > > > > > On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano < > > > st...@pearwood.info> wrote: > >

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11.04.16 00:53, Jon Ribbens wrote: Try following example: it = iter([1]) for i in range(100): it = filter(None, it) next(it) That does indeed segfault. I guess you should report that as a bug! There is old issue that doesn't have adequate solution. And this is

Re: [Python-Dev] Challenge: Please break this! (a.k.a restricted mode revisited)

On 11 April 2016 at 13:49, Tres Seaver wrote: > -BEGIN PGP SIGNED MESSAGE- > Hash: SHA1 > > On 04/10/2016 06:31 PM, Jon Ribbens wrote: >> Unless someone knows a way to get to an object's __dict__ or its type >> without using vars() or type() or underscore attributes... > > Hmm, 'classmetho