Re: The Case Against Python 3

On Thursday, December 1, 2016 at 9:03:46 AM UTC-5, Paul Moore wrote: > While I agree that f-strings are more dangerous than people will immediately > realise (the mere fact that we call them f-*strings* when they definitely > aren't strings is an example of that), the problem here is clearly

Re: The Case Against Python 3

On Tuesday, 29 November 2016 01:01:01 UTC, Chris Angelico wrote: > So what is it that's trying to read something and is calling an > f-string a mere string? gettext.c2py: """Gets a C expression as used in PO files for plural forms and returns a Python lambda function that implements an

Re: The Case Against Python 3

On Tue, Nov 29, 2016 at 10:54 AM, Steve D'Aprano wrote: > Now you're just being silly, this isn't "anything", it is a specific design > decision: something which looks like, and is treated by the tokeniser, as a > string but is actually a hidden call to eval. > This,

Re: The Case Against Python 3

On Tue, 29 Nov 2016 09:35 am, Gregory Ewing wrote: > Steve D'Aprano wrote: >> I daresay you are right that a sufficiently clever adversary may have >> found an exploit. But there's no sign that anyone actually did find an >> exploit, until f-strings made exploiting this trivial. > > The person

Re: The Case Against Python 3

Gregory Ewing writes: > I agree that f-strings are not to blame here. If we really want to > avoid breaking anyone's ill-conceived attempts at sandboxing eval, > we'd better not add anything more to the language, ever, because > nobody can foresee all the possible

Re: The Case Against Python 3

Steve D'Aprano wrote: I daresay you are right that a sufficiently clever adversary may have found an exploit. But there's no sign that anyone actually did find an exploit, until f-strings made exploiting this trivial. The person who wrote the bug report found at least one way of exploiting it

Re: The Case Against Python 3

You're right. Didn't look closely enough at it in my phone. Still don't think i'd recommend this in a general solution, though. You effectively have to white-list code snippets. Not very useful. On Nov 26, 2016 7:51 PM, "Michael Torrie" wrote: > On 11/26/2016 06:26 PM, Nathan

Re: The Case Against Python 3

On 11/26/2016 06:26 PM, Nathan Ernst wrote: > Sure, what if the input used a double quote instead of single, cursory > glance looks like it might vulnerable. Either a single quote or a double quote would not pass the sanitizer. Or am I misunderstanding you? --

Re: The Case Against Python 3

Sure, what if the input used a double quote instead of single, cursory glance looks like it might vulnerable. (Not trying to be argumentative here) On Nov 26, 2016 7:21 PM, "Steve D'Aprano" wrote: > On Sun, 27 Nov 2016 11:25 am, Chris Angelico wrote: > > > On Sun,

Re: The Case Against Python 3

On Sun, 27 Nov 2016 11:25 am, Chris Angelico wrote: > On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano > wrote: >> So-called f-strings haven't even hit the already been implicated in a >> code-injection vulnerability: >> >> http://bugs.python.org/issue28563 >> >> I

Re: The Case Against Python 3

On Sun, Nov 27, 2016 at 11:13 AM, Steve D'Aprano wrote: > So-called f-strings haven't even hit the already been implicated in a > code-injection vulnerability: > > http://bugs.python.org/issue28563 > > I feel kind of vindicated here, because when so-called f-strings

Re: The Case Against Python 3

On Sat, 26 Nov 2016 07:01 pm, Ian Kelly wrote: > When I read that Python 3.6 would include f-strings, I turned to the > coworker sitting next to me and said, "Oh my god, Python is adding yet > another new syntax for string formatting." It's getting to be a joke. f-strings are not merely string

Re: The Case Against Python 3

On 2016-11-26 01:01, Ian Kelly wrote: > When I read that Python 3.6 would include f-strings, I turned to the > coworker sitting next to me and said, "Oh my god, Python is adding > yet another new syntax for string formatting." It's getting to be a > joke. Pretty soon Python will have one

Re: The Case Against Python 3

On Fri, Nov 25, 2016 at 1:29 AM, Mark Summerfield wrote: > The article has a section called: > > "Too Many Formatting Options" > > He's right! The % formatting was kept to help port old code, the new > .format() which is far more versatile is a bit verbose, so finally

Re: The Case Against Python 3

Chris Angelico wrote: but brace-formatting lets you reorder the parameters, so it has flexibility that can be important for i18n. Actually, Python's version of %-formatting lets you reorder the parameters as well. The brace syntax for this is easier to read and write, though, so probably

Re: The Case Against Python 3

On 25 November 2016 at 12:11, Fabien wrote: > I'd be interested to read what the community thinks about the fact that his > book (learn the hard way) is extremely influential among beginners, and what > tools do we have to avoid that beginners stumble across such

Re: The Case Against Python 3

On 11/25/2016 09:29 AM, Mark Summerfield wrote: On Thursday, November 24, 2016 at 7:35:03 PM UTC, bream...@gmail.com wrote: > It's all here https://learnpythonthehardway.org/book/nopython3.html I think the article is full of factual errors and is at best misleading > and at worst downright

Re: The Case Against Python 3

On Fri, Nov 25, 2016 at 7:29 PM, Mark Summerfield wrote: > The article has a section called: > > "Statically Typed Strings" > > The title is wrong of course because Python uses dynamic typing. But his > chief complaint seems to be that you can't mix strings and bytes in

Re: The Case Against Python 3

On Thursday, November 24, 2016 at 7:35:03 PM UTC, bream...@gmail.com wrote: > It's all here https://learnpythonthehardway.org/book/nopython3.html although > I strongly suggest that people have large piles of sedatives to hand before > reading the article. Does me a favour though, i've been