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

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

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

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

Re: [Python-Dev] Incomplete Internationalization in Argparse Module

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

[Python-Dev] Question about the current implementation of str

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

Re: [Python-Dev] Defining a path protocol

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

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

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

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

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

Re: [Python-Dev] Defining a path protocol

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

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

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

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

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

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

> 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

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

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 ___

Re: [Python-Dev] Defining a path protocol

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 >

Re: [Python-Dev] Defining a path protocol

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

Re: [Python-Dev] Incomplete Internationalization in Argparse Module

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

[Python-Dev] Incomplete Internationalization in Argparse Module

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

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

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

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

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

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

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

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

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

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

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!

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

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

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

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',

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

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

[Python-Dev] Pathlib enhancments - method name only

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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 -

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

Re: [Python-Dev] Defining a path protocol

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

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

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

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

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')

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

Re: [Python-Dev] Defining a path protocol

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?

Re: [Python-Dev] Defining a path protocol

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

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

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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.

[Python-Dev] Summary of Python tracker Issues

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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 >

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

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

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

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

Re: [Python-Dev] Defining a path protocol

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?

Re: [Python-Dev] Defining a path protocol

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

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

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 >

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

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

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

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 >

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

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

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

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

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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 ___

Re: [Python-Dev] Defining a path protocol (was: When should pathlib stop being provisional?)

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

Re: [Python-Dev] summary: a Path protocol

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")

Re: [Python-Dev] summary: a Path protocol

Sorry, I don't have time to read the whole discussion. What is the problem with adding a __str__ to pathlib? Victor ___ Python-Dev mailing list Python-Dev@python.org https://mail.python.org/mailman/listinfo/python-dev Unsubscribe:

[Python-Dev] summary: a Path protocol

The discussion has ranged all over, so let me try to sum up: Name: __ospath__ Method or attribute? Method (implementations are of course free to pre-build and/or cache the value) Built-in? no, rather a function in pathlib - ospath() Add the method/attribute to str? Not

Re: [Python-Dev] Defining a path protocol

Chris Angelico wrote: -1 for __os_path__, unless it's reasonable to justify it as "most of the standard library uses Path objects, but os.path uses strings, so before you pass a Path to anything in os.path, you call path.ospath() on it, which calls __os_path__()". A less roundabout