Re: [Python-Dev] pathlib (was: Defining a path protocol)

Nick Coghlan wrote: We want to be able to readily use the protocol helper in builtin modules like os and low level Python modules like os.path, which means we want it to be much lower down in the import hierarchy than pathlib. Also, it's more general than that. It works on any object that

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

On 9 April 2016 at 23:02, R. David Murray wrote: That is, a 'filename' is the identifier we've assigned to this thing pointed to by an inode in linux, but an os path is a text representation of the path from the root filename to a specified filename. That is, the path

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

Eric Snow wrote: All this matters because it impacts the value returned from __ospath__(). Should it return the string representation of the path for the current OS or some standardized representation? What standardized representation? I'm not aware of such a thing. I'd expect the former.

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

On 10 April 2016 at 15:58, Greg Ewing wrote: > Brett Cannon wrote: > >> Depends if you use `/` or `\` as your path separator > > > Or whether your pathnames look entirely different, e.g VMS: > > device:[topdir.subdir.subsubdir]filename.ext;version > > Pathnames are

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

On 04/10/2016 12:36 AM, Nick Coghlan wrote: On 10 April 2016 at 17:12, Greg Ewing wrote: But there needs to be some way to ask a path object for its native string representation, otherwise there would be no point in using foreign path objects at all. In addition to the existing

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

On Sun, 10 Apr 2016 18:51:23 +1200, Greg Ewing wrote: > > On 9 April 2016 at 23:02, R. David Murray wrote: > > > >>That is, a 'filename' is the identifier we've assigned to this thing > >>pointed to by an inode in linux, but an os path is a

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

> On Apr 10, 2016, at 2:43 AM, Nick Coghlan wrote: > > This does raise a concrete API design question: how should > PurePath.__fspath__ behave when called on a mismatched OS? I think that PurePath.__fspath__ should return a string. There’s no reason why we can’t in my

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] Challenge: Please break this! (a.k.a restricted mode revisited)

On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > On 9 April 2016 at 22:43, Victor Stinner wrote: > > See pysandbox test suite for a lot of ways to escape a sandbox. CPython has > > a list of know code to crash CPython (I don't recall the dieectory in > >

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

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 be good to try to

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

On 04/09/2016 10:31 PM, Nick Coghlan wrote: On 10 April 2016 at 02:41, Ethan Furman wrote: When somebody hands you bytes rather than text you need to worry about the encoding, and you need to worry about returning bytes rather than text yourself.

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

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): >https://lwn.net/Articles/574323/ > >

[Python-Dev] pathlib+os/shutil feedback

I talked to my colleague. He didn't remember the concrete use-case, though, he instantly mentioned three possible things (no order of preference): 1) pathlib + mtime 2) os.walk and pathlib 3) creation/removal of paths He wasn't too sure but I checked with the docs and his memories seemed to

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

Brett Cannon wrote: Depends if you use `/` or `\` as your path separator Or whether your pathnames look entirely different, e.g VMS: device:[topdir.subdir.subsubdir]filename.ext;version Pathnames are very much OS-dependent in both syntax *and* semantics. Even the main two in use today

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

On 10 April 2016 at 08:36, Nick Coghlan wrote: > In addition to the existing "str(pathobj)", a "path" property was > recently added for that purpose: > >>>> import pathlib >>>> pathlib.PureWindowsPath(".") >PureWindowsPath('.') >>>>

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

Nick Coghlan wrote: Similar to my proposal for dealing with DirEntry.path being a bytes-like object, I'd like to suggest raising TypeError in __fspath__ if the request is nonsensical for the currently running system - *nix systems can *manipulate* Windows paths (and vice-versa), but actually

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

On 10 April 2016 at 17:12, Greg Ewing wrote: > Nick Coghlan wrote: >> >> Similar to my proposal for dealing with DirEntry.path being a >> bytes-like object, I'd like to suggest raising TypeError in __fspath__ >> if the request is nonsensical for the currently running

Re: [Python-Dev] PEP 506 secrets module

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 PEP. (If you don't have write access to the peps repo, send the new version to

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

On Mon, Apr 11, 2016 at 01:09:19PM +1000, Steven D'Aprano wrote: > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > wrote: > > > I haven't looked at your sandbox but for a

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

On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > wrote: > > I haven't looked at your sandbox but for a different approach try this one: > > > > L = [None] > > L.extend(iter(L)) > > > > On my Linux

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

-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, 'classmethod'-wrapped functions get passed the type. Tres. - --

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

On Mon, Apr 11, 2016 at 12:07:48AM +0300, Serhiy Storchaka wrote: > On 10.04.16 19:51, Jon Ribbens wrote: > >On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > >>On 9 April 2016 at 22:43, Victor Stinner wrote: > >>>See pysandbox test suite for a lot of ways

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

On Apr 10 2016, Jon Ribbens wrote: > 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

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

On 10.04.16 19:51, Jon Ribbens wrote: On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: On 9 April 2016 at 22:43, Victor Stinner wrote: See pysandbox test suite for a lot of ways to escape a sandbox. CPython has a list of know code to crash CPython (I

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

On 10 Apr 2016 22:55, "Jon Ribbens" wrote: > > On Mon, Apr 11, 2016 at 12:07:48AM +0300, Serhiy Storchaka wrote: > > On 10.04.16 19:51, Jon Ribbens wrote: > > >On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > > >>On 9 April 2016 at 22:43, Victor

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

On Apr 10, 2016 11:51 AM, "Jon Ribbens" wrote: > > On Sun, Apr 10, 2016 at 02:51:23PM +1000, Nick Coghlan wrote: > > On 9 April 2016 at 22:43, Victor Stinner wrote: > > > See pysandbox test suite for a lot of ways to escape a sandbox.

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

On Sun, Apr 10, 2016 at 02:08:16PM -0700, Nikolaus Rath wrote: > On Apr 10 2016, Jon Ribbens wrote: > > On Sat, Apr 09, 2016 at 02:43:19PM +0200, Victor Stinner wrote: > > That's the opposite of my approach though - I'm starting small and > > adding things, not

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

On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin wrote: > I haven't looked at your sandbox but for a different approach try this one: > > L = [None] > L.extend(iter(L)) > > On my Linux machine that doesn't just crash Python. For the record: don't try this if you

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

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: > > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote: > > > On Sun, Apr 10, 2016 at 7:02 PM, Oscar Benjamin > > >