On 8 April 2016 at 00:25, Jim J. Jewett wrote:
> (1) I think the "built-in" should instead be a module-level function
> in the pathlib. If you aren't already expecting pathlib paths, then
> you're just expecting strings to work anyhow, and a builtin isn't
> likely to be helpful.
Concrete data i
On Fri, Apr 8, 2016 at 7:41 PM, Brett Cannon wrote:
>
>
> On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote:
>>
>> On 4/8/2016 3:28 PM, Eric Snow wrote:
>>
>> All this matters because it impacts the value returned from
>> __ospath__(). Should it return the string representation of the path
>> for
On Fri, Apr 8, 2016, 16:13 Glenn Linderman wrote:
> On 4/8/2016 3:28 PM, 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? I'd expect
>
That string looks like it is aimed at the developer, not the user of
the program, so it makes sense not to translate it.
On Fri, Apr 8, 2016 at 2:07 PM, Brett Cannon wrote:
>
>
> On Fri, 8 Apr 2016 at 14:05 Grady Martin wrote:
>>
>> Hello, all. I was wondering if the following string was left u
I have a straightforward question about the str object, specifically the
PyUnicodeObject. I've tried reading the source to answer the question
myself but it's nearly impenetrable. So I was hoping someone here who
understands the current implementation could answer it for me.
Although the
On 04/08/2016 04:05 PM, Koos Zevenhoven wrote:
On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote:
On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:
At this point no one wants to touch bytes paths. If you need that level of
control because of multiple encodings within a single file system the
On 4/8/2016 3:28 PM, 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? I'd expect
the former. However, if that is the expectation then somethi
On 4/8/2016 11:25 AM, Brett Cannon wrote:
I personally still like __ospath__ as well.
+1. Because they aren't always files... but what else they might be is
os dependent.
___
Python-Dev mailing list
Python-Dev@python.org
https://mail.python.org/mailman
On Sat, Apr 9, 2016 at 12:53 AM, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:
>
> At this point no one wants to touch bytes paths. If you need that level of
> control because of multiple encodings within a single file system then you
> will probably have to stick with
On Fri, Apr 8, 2016 at 3:57 PM, Eric Snow wrote:
> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file system.
Hmm. It's importan
On Fri, 8 Apr 2016 at 15:21 Chris Barker - NOAA Federal <
chris.bar...@noaa.gov> wrote:
> > On Apr 8, 2016, at 3:00 PM, Eric Snow
> wrote:
> >
> >> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
> >> I personally still like __ospath__ as well.
> >
> > Same here. The strings are essentiall
> On Apr 8, 2016, at 3:00 PM, Eric Snow wrote:
>
>> On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
>> I personally still like __ospath__ as well.
>
> Same here. The strings are essentially an OS-dependent serialization,
> rather than related to a particular file system.
Huh? I though the
On Fri, Apr 8, 2016 at 12:25 PM, Brett Cannon wrote:
> I personally still like __ospath__ as well.
Same here. The strings are essentially an OS-dependent serialization,
rather than related to a particular file system.
-eric
___
Python-Dev mailing list
On Fri, 8 Apr 2016 at 14:23 Koos Zevenhoven wrote:
> On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote:
> > On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote:
> >> > I thought the whole point off all this is that not any old string can
> be
> >> > a path! (whereas any int can be an index). Unless
On Fri, Apr 8, 2016 at 8:34 PM, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote:
>> > I thought the whole point off all this is that not any old string can be
>> > a path! (whereas any int can be an index). Unless we go with Chris A's
>> > suggestion that this be a more gener
On Fri, 8 Apr 2016 at 14:05 Grady Martin wrote:
> Hello, all. I was wondering if the following string was left untouched by
> gettext for a purpose (from line 720 of argparse.py, in class
> ArgumentError):
>
> 'argument %(argument_name)s: %(message)s'
>
> There may be other untranslatable string
Hello, all. I was wondering if the following string was left untouched by
gettext for a purpose (from line 720 of argparse.py, in class ArgumentError):
'argument %(argument_name)s: %(message)s'
There may be other untranslatable strings in the argparse module, but I have
yet to encounter them
On Fri, Apr 8, 2016 at 11:39 PM, R. David Murray wrote:
> On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote:
>> On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
>>
>> > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
>> > wrote:
>> > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
>> > w
On Fri, 08 Apr 2016 19:24:44 -, Brett Cannon wrote:
> On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
>
> > On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
> > wrote:
> > > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
> > wrote:
> > >>
> > >> >
> > >> > __pathstr__ # pathstring
> > >> >
On Fri, 8 Apr 2016 at 12:10 Chris Angelico wrote:
> On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker
> wrote:
> > On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven
> wrote:
> >>
> >> >
> >> > __pathstr__ # pathstring
> >> >
> >>
> >> Or perhaps __pathstring__ in case it may be or return byte strings
On Sat, Apr 9, 2016 at 5:03 AM, Chris Barker wrote:
> On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven wrote:
>>
>> >
>> > __pathstr__ # pathstring
>> >
>>
>> Or perhaps __pathstring__ in case it may be or return byte strings.
>
>
> I'm fine with __pathstring__ , but I thought it was already deci
On Fri, Apr 8, 2016 at 11:34 AM, Koos Zevenhoven wrote:
> >
> > __pathstr__ # pathstring
> >
>
> Or perhaps __pathstring__ in case it may be or return byte strings.
>
I'm fine with __pathstring__ , but I thought it was already decided that it
would NOT return a bytestring!
-CHB
--
Christoph
On Fri, Apr 8, 2016 at 9:20 PM, Chris Barker wrote:
>
> we rejected plain old __path__ because this is already ued in another
> context, but if we add "str" on the end, that's not longer an issue, so do
> we need the "fs"?
>
> __pathstr__ # pathstring
>
Or perhaps __pathstring__ in case it may be
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:02 AM, Koos Zevenhoven wrote:
>
> >>> I'm still thinking a little bit about 'pathname', which to me sounds
>
On Fri, Apr 8, 2016 at 11:13 AM, Ethan Furman wrote:
> So the plausible choices are, I think:
>
> - __fspath__ # File System Path -- possible confusion with Path
>
> - __fsstr__ # File System String
I think we really need "path" in there somewhere
>
> - __fspathstr__ # File System Path
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:02 AM, Koos Zevenhoven wrote:
>>> I'm still thinking a little bit about 'pathname', which to me sounds
>>> more like a string than fspath does.
>>
>>
>> I like that a
On Fri, Apr 8, 2016 at 7:42 PM, Chris Barker wrote:
> On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
>>
>> I'm still thinking a little bit about 'pathname', which to me sounds
>> more like a string than fspath does [1].
>
>
> I like that a lot - or even "__pathstr__" or "__pathstring__"
>
On 04/08/2016 09:42 AM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
While I can only make guesses about what happened, these kinds of
>> things easily make you go from "Hey, maybe I'll be able to do something
>> to improve Python!" to "These people don't seem to
On Fri, 8 Apr 2016 at 09:39 Ethan Furman wrote:
> On 04/08/2016 09:04 AM, Chris Barker wrote:
> > On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
>
> >> Method, as long as there's a helper function somewhere
> >
> > what has the helper function got to do with whether it's a method or
> > attr
On Sat, Apr 09, 2016 at 02:20:49AM +1000, Chris Angelico wrote:
> On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens
> wrote:
> > Anyway the code is at https://github.com/jribbens/unsafe
> > It requires Python 3.4 or later (it could probably be made to work on
> > Python 2.7 as well, but it would need s
On Fri, 8 Apr 2016 at 09:13 Koos Zevenhoven wrote:
> Nick Coghlan wrote:
> > On 7 April 2016 at 03:26, Brett Cannon wrote:
> >>
> >> Name: __path__, __fspath__, or something else?
> >
> > __fspath__
> >
>
> I think I might like this dunder name because it does not clutter the
> list of regular m
On Fri, 8 Apr 2016 at 09:05 Chris Barker wrote:
> On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
>
>> On 7 April 2016 at 03:26, Brett Cannon wrote:
>>
>
>
>> > Method or attribute? (changes what kind of one-liner you might use in
>> > libraries, but I think historically all protocols have
On Fri, Apr 08, 2016 at 05:49:12PM +0200, Marcin Kościelnicki wrote:
> On 08/04/16 16:18, Jon Ribbens wrote:
> That one is trivially fixable, but here goes:
>
> async def a():
> global c
> c = b.cr_frame.f_back.f_back.f_back
>
> b = a()
> b.send(None)
> c.f_builtins['print']('broken')
Ah
On Fri, Apr 8, 2016 at 9:02 AM, Koos Zevenhoven wrote:
> I'm still thinking a little bit about 'pathname', which to me sounds
> more like a string than fspath does [1].
I like that a lot - or even "__pathstr__" or "__pathstring__"
after all, we're making a big deal out of the fact that a path
On 04/08/2016 09:04 AM, Chris Barker wrote:
On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
Method, as long as there's a helper function somewhere
what has the helper function got to do with whether it's a method or
attribute (would we call a property an attribute here?)
Built-in? (nam
On 04/08/2016 08:41 AM, Brett Cannon wrote:
On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote:
>> Brett previously queried:
Add the method/attribute to str? (I assume so, much like
__index__() is on int, but I have not seen it explicitly
>>> stated so I would rather clarify it)
What will this
On Sat, Apr 9, 2016 at 12:18 AM, Jon Ribbens
wrote:
> Anyway the code is at https://github.com/jribbens/unsafe
> It requires Python 3.4 or later (it could probably be made to work on
> Python 2.7 as well, but it would need some changes).
Not being a security expert, I'm not the best one to try to
Nick Coghlan wrote:
> On 7 April 2016 at 03:26, Brett Cannon wrote:
>>
>> Name: __path__, __fspath__, or something else?
>
> __fspath__
>
I think I might like this dunder name because it does not clutter the
list of regular methods and attributes, and is perhaps more pythonic.
>> Method or attri
ACTIVITY SUMMARY (2016-04-01 - 2016-04-08)
Python tracker at http://bugs.python.org/
To view or respond to any of the issues listed below, click on the issue.
Do NOT respond to this message.
Issues counts and deltas:
open5477 ( +6)
closed 32993 (+22)
total 38470 (+28)
Open issues wit
On Fri, Apr 8, 2016 at 2:50 AM, Nick Coghlan wrote:
> On 7 April 2016 at 03:26, Brett Cannon wrote:
>
> > Method or attribute? (changes what kind of one-liner you might use in
> > libraries, but I think historically all protocols have been methods and
> the
> > serialized string representation
On 08/04/16 16:18, Jon Ribbens wrote:
I've made another attempt at Python sandboxing, which does something
which I've not seen tried before - using the 'ast' module to do static
analysis of the untrusted code before it's executed, to prevent most
of the sneaky tricks that have been used to break
On Fri, Apr 08, 2016 at 05:21:38PM +0200, Arthur Darcet wrote:
>If i'm not mistaken, this breaks out:
>> exec('open("out", "w").write("a")', {})
>because if the second argument of exec does not contain a __builtins__
>key, then a copy of the original builtins module is inserted:
>
On Fri, 8 Apr 2016 at 08:33 Ethan Furman wrote:
> On 04/08/2016 02:50 AM, Nick Coghlan wrote:
>
> >> Built-in? (name is dependent on #1 if we add one)
> >
> > os.fspath (alongside os.fsencode and os.fsdecode)
>
> I like this better.
>
>
> >> Add the method/attribute to str? (I assume so, much lik
On 04/08/2016 02:50 AM, Nick Coghlan wrote:
Built-in? (name is dependent on #1 if we add one)
os.fspath (alongside os.fsencode and os.fsdecode)
I like this better.
Add the method/attribute to str? (I assume so, much like __index__() is on
int, but I have not seen it explicitly stated so I
On 8 April 2016 at 16:18, Jon Ribbens
wrote:
> I've made another attempt at Python sandboxing, which does something
> which I've not seen tried before - using the 'ast' module to do static
> analysis of the untrusted code before it's executed, to prevent most
> of the sneaky tricks that have been
On Fri, Apr 08, 2016 at 03:37:45PM +0100, Paul Moore wrote:
> On 8 April 2016 at 15:18, Jon Ribbens
> wrote:
> > I would be very interested to see if anyone can manage to break it.
> > Bugs which are trivially fixable are of course welcomed, but the real
> > question is: is this approach basicall
On 8 April 2016 at 15:18, Jon Ribbens wrote:
> I would be very interested to see if anyone can manage to break it.
> Bugs which are trivially fixable are of course welcomed, but the real
> question is: is this approach basically sound, or is it fundamentally
> unworkable?
What are the limitations
I've made another attempt at Python sandboxing, which does something
which I've not seen tried before - using the 'ast' module to do static
analysis of the untrusted code before it's executed, to prevent most
of the sneaky tricks that have been used to break out of past attempts
at sandboxes.
In s
I like __fspath__ because it looks like os.fsencode() and os.fsdecode().
Please no builtin function, we have enough of them, but make sure that the
__fspath__ is accepted in all functions expecting a filename.
If you consider that a function would make your change simpler, I suggest
to add os.fsp
FYI the doc of the builtin functions is the #1 in stats of docs python.org.
I also read this doc every week, even if I consider that I know well
Python. IMHO it's not an issue to regulary read the doc.
Victor
___
Python-Dev mailing list
Python-Dev@pytho
Please write a new PEP.
The topic looks to be discussed since many months by many different people
on different mailing list. A PEP is a good standard to take a decision and
it became clear that a decision must be taken for pathlib.
Victor
___
Python-De
On 7 April 2016 at 03:26, 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
On Fri, Apr 8, 2016 at 4:35 PM, Victor Stinner wrote:
> Sorry, I don't have time to read the whole discussion. What is the problem
> with adding a __str__ to pathlib?
>
> Victor
Everything else has __str__ too, so you run the risk of open(["Hello",
"World"], "w") working and doing something weird
53 matches
Mail list logo
