<div dir="ltr"><div class="gmail_extra"><div class="gmail_quote"><div class="gmail_quote">On Tue, Mar 29, 2016 at 10:49 AM, Paul Moore <span dir="ltr"><<a href="mailto:p.f.moore@gmail.com" target="_blank">p.f.moore@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On 29 March 2016 at 08:22, Sven R. Kunze <<a href="mailto:srkunze@mail.de">srkunze@mail.de</a>> wrote:<br>> Thinking more about it, that would even come in nicely with path separators:<br>><br>> p'/{whereever}/{youwant}/{togo}'<br>><br>> That'll finally an easy-to-write and readable path generation. Great idea,<br>> Stephen.<br><br></span>P(wherever)/youwant/togo<br><br>is as good, if not better - just "from pathlib import Path as P" (or<br>use Path(wherever) if you don't like unnecessary 1-letter aliases...)</blockquote></div></div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">Yes. I assume you meant  P('/') /wherever/youwant/togo. Or with p-strings,</div><div class="gmail_quote"><br></div><div class="gmail_quote">    p'/' /wherever/youwant/togo</div><div class="gmail_quote"><br></div><div class="gmail_quote">I'm not necessarily against Sven's version either, but my first thoughts about the power of combined pf strings would be something like this (assuming Sven's implicit f):</div><div class="gmail_quote"><br></div><div class="gmail_quote">    all_data = [p'data{i}.txt'.read_text() for i in range(1, 307)]</div><div class="gmail_quote"><br></div><div class="gmail_quote">which would read the contents of data1.txt, data2.txt, ..., and data306.txt into a list. </div><div class="gmail_quote"><br></div><div class="gmail_quote">And below, to the security issue raised by Sjoerd.</div><div class="gmail_quote"><br></div><div class="gmail_quote"><br></div><div class="gmail_quote">On Tue, Mar 29, 2016 at 10:46 AM, Sjoerd Job Postmus <span dir="ltr"><<a href="mailto:sjoerdjob@sjec.nl" target="_blank">sjoerdjob@sjec.nl</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class="">On Tue, Mar 29, 2016 at 06:27:09PM +1100, Chris Angelico wrote:<br>
> On Tue, Mar 29, 2016 at 6:22 PM, Sven R. Kunze <<a href="mailto:srkunze@mail.de">srkunze@mail.de</a>> wrote:<br>
> > Thinking more about it, that would even come in nicely with path separators:<br>
> ><br>
> > p'/{whereever}/{youwant}/{togo}'<br>
> ><br>
> > That'll finally an easy-to-write and readable path generation. Great idea,<br>
> > Stephen.<br>
><br>
> Agreed, although this introduces a new edge case: what if 'togo'<br>
> contains a slash? Should this raise an exception, or should it be<br>
> interpreted as a multi-part path component? Arguments can be put for<br>
> both sides.<br>
<br>
</span>As we all know, togo is user input containing<br>
    ../../../../../../../../../../../../../../../etc/passwd<br>
<br></blockquote><div><br></div><div>How about</div><div><br></div><div>    p'/' /wherever/youwant//togo</div><div><br></div><div>That is, the floordiv operator could be used to prevent 'togo' from going up the directory tree with "../../" or "/etc/passwd". The // would thus restrict the user (who provides `togo`) into /wherever/youwant/ and it its subdirectories.</div><div><br></div><div>-Koos</div><div><br></div></div></div></div>