> On Apr 10, 2016, at 11:43 AM, Guido van Rossum wrote:
>
> I will approve the PEP as soon as you've updated the two function
> names in the PEP.
Congratulations Steven.
Raymond
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python
On 11 April 2016 at 02:16, Ethan Furman wrote:
> 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
>
On 11 April 2016 at 01:50, Donald Stufft wrote:
>
>> 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
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:
> > > On Sun, Apr 10, 2016 at 08:12:30PM -0400, Jonathan Goble wrote:
> > > > On
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
> > > wrote:
> > > > I have
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 different approach try this
> > > one:
> > >
> > >
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 machine that doesn't just cras
-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.
- --
===
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 have unsaved files open on your
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 Stinner
wrote:
> > >>>See pysandbox
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 starting with everything and removin
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 to escape a sandbox. CPytho
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 about my attempt (pysandbox):
>>h
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 don't recall the dieectory in
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.
CPython has
> > > a list of know code to crash CPython (I don'
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 p..
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
> > sources), even with the late
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/
>
>And
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 code
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. https://hg.python.org/cpython/rev/e44410e5928e#
> 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 opinion and doing so just
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 "str(pathobj)
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 text representation
> >>of the path from the root file
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 improve pathlib based
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 b
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('.')
>>>> pathlib.PureWindowsPath(".").path
>'.'
>
> (T
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 system - *nix
>> systems can *
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
tryi
28 matches
Mail list logo