Be Careful with Python's New-Style String Format • Hacker News Board

Re: Be Careful with Python's New-Style String Format

#41

Post by UnoriginalGuy » Sat, Dec 31, 2016, 9:05 PM UTC

Cyph0n wrote: post #28

Scala's solution to string formatting is the best out there imo. You can put basically any code into the format placeholder. http://docs.scala-lang.org/overviews/core/string-interpolati...

I don't really understand what you mean. They're pointing out unintended consequences of allowing arbitrary string formats. You're linking to one you call "better" which would allow even more powerful misuse of arbitrary string formats.

And while Scala's string formatting looks cool, it hardly seems like your reply applies to the topic/thread. In fact ironically it seems to point out that this would be an even bigger issue in Scala.

Re: Be Careful with Python's New-Style String Format

#42

Post by stevebmark » Sat, Dec 31, 2016, 9:11 PM UTC

Doesn't this apply to any language that has string interpolation, Ruby, Python, Javascript Perl, etc? And doesn't it not really matter, because it's not realistic to use a dynamic string template in a program?

Re: Be Careful with Python's New-Style String Format

#43

Post by merb » Sat, Dec 31, 2016, 9:18 PM UTC

UnoriginalGuy wrote: post #41

Cyph0n wrote: post #28

Scala's solution to string formatting is the best out there imo. You can put basically any code into the format placeholder. http://docs.scala-lang.org/overviews/core/string-interpolati...

I don't really understand what you mean. They're pointing out unintended consequences of allowing arbitrary string formats. You're linking to one you call "better" which would allow even more powerful misuse of arbitrary string formats. And while Scala's string formatting looks cool, it hardly seems like your reply applies to the topic/thread. In fact ironically it seems to point out that this would be an even bigger…

> be an even bigger issue in Scala.

not with string interpolation in scala. it only works on compile time so it's not possible to actually take user input strings (without runtime reflection of course)

> it hardly seems like your reply applies to the topic/thread

yes string interpolation (scala) has less todo with it. it can't be compared to the python one.

Re: Be Careful with Python's New-Style String Format

#44

Post by kazinator » Sat, Dec 31, 2016, 9:24 PM UTC

merb wrote: post #43

UnoriginalGuy wrote: post #41

Earlier quoted context omitted.

I don't really understand what you mean. They're pointing out unintended consequences of allowing arbitrary string formats. You're linking to one you call "better" which would allow even more powerful misuse of arbitrary string formats. And while Scala's string formatting looks cool, it hardly seems like your reply applies to the topic/thread. In fact ironically it seems to point out that this would be an even bigger…

> be an even bigger issue in Scala. not with string interpolation in scala. it only works on compile time so it's not possible to actually take user input strings (without runtime reflection of course) > it hardly seems like your reply applies to the topic/thread yes string interpolation (scala) has less todo with it. it can't be compared to the python one.

What the Python code is doing is arguably a form of run-time reflection. Format strings contain embedded variables and expression, and the format function evaluates them: hence reflection.

Format strings occurring as literals in Python source could be treated at compile time, like in Scala.

Re: Be Careful with Python's New-Style String Format

#45

Post by icebraining » Sat, Dec 31, 2016, 9:26 PM UTC

merb wrote: post #43

UnoriginalGuy wrote: post #41

Earlier quoted context omitted.

I don't really understand what you mean. They're pointing out unintended consequences of allowing arbitrary string formats. You're linking to one you call "better" which would allow even more powerful misuse of arbitrary string formats. And while Scala's string formatting looks cool, it hardly seems like your reply applies to the topic/thread. In fact ironically it seems to point out that this would be an even bigger…

> be an even bigger issue in Scala. not with string interpolation in scala. it only works on compile time so it's not possible to actually take user input strings (without runtime reflection of course) > it hardly seems like your reply applies to the topic/thread yes string interpolation (scala) has less todo with it. it can't be compared to the python one.

Python's string interpolation only works on compile time as well¹, this isn't interpolation, it's a runtime method in the string class, which Scala also has, in fact, with the same name (.format).

¹ (compilation in CPython generally occurs during initialization of the execution, though you can pre-compile files manually)

Re: Be Careful with Python's New-Style String Format

#46

Post by anamoulous » Sat, Dec 31, 2016, 9:26 PM UTC

jsjohnst wrote: post #32

dlbucci wrote: post #5

I do love writing python, but it's pretty shocking when I find out you can write something like `event.__init__.__globals__[CONFIG][SECRET_KEY]`. That language just does not care about privacy or information hiding at all, I guess.

I'd love to hear your perspectives on Ruby if this bothers you that much.

What does Ruby have to do with any of this?

Re: Be Careful with Python's New-Style String Format

#47

Post by merb » Sat, Dec 31, 2016, 9:33 PM UTC

icebraining wrote: post #45

merb wrote: post #43

Earlier quoted context omitted.

> be an even bigger issue in Scala. not with string interpolation in scala. it only works on compile time so it's not possible to actually take user input strings (without runtime reflection of course) > it hardly seems like your reply applies to the topic/thread yes string interpolation (scala) has less todo with it. it can't be compared to the python one.

Python's string interpolation only works on compile time as well¹, this isn't interpolation, it's a runtime method in the string class, which Scala also has, in fact, with the same name (.format). ¹ (compilation in CPython generally occurs during initialization of the execution, though you can pre-compile files manually)

thanks for correcting me, actually my statement is not wrong that it has nothing to do with `.format` I was just mistaken about the python code, I tought it means the new stuff (i.e. interpolation), but I actually skipped the first code snippet.

Re: Be Careful with Python's New-Style String Format

#48

Post by wfunction » Sat, Dec 31, 2016, 9:37 PM UTC

anderskaseorg wrote: post #39

The proposed idea of relying on undocumented internals and blacklisting attribute names to securely sandbox formatting strings is _really_ _dangerous_. Never do that in production code! Language expansions could render your sandbox unsafe at any time. You can write your own safe formatting engine in much less code. def safe_format(fmt, **args): return re.sub(r'\{([^{}]*)\}', lambda m: args.get(m.group(1)), fmt) safe_…

+1 I freaked out when I saw it. Blacklists are just asking to get hacked.

Re: Be Careful with Python's New-Style String Format

#49

Post by the_mitsuhiko » Sat, Dec 31, 2016, 9:37 PM UTC

innocentoldguy wrote: post #31

While I agree this is a possible attack vector, I think it is extremely unlikely, at least in the localization realm, for several reasons: 1. The localization company should never know what programming language you're using. 2. You shouldn't give localization companies direct access to your internal strings. More than hacking your code, they're almost guaranteed to screw the formatting up. 3. Typically, translators a…

Most internationalization these days goes through things like transifex. Becoming a translator on a specific project is not completely unlikely if you want to target it.

Re: Be Careful with Python's New-Style String Format

#50

Post by detaro » Sat, Dec 31, 2016, 9:38 PM UTC

gizmo686 wrote: post #17

Animats wrote: post #9

No, Rust does not have the ability to access any variable in the program via a format string. Rust has this: format!("{argument}", argument = "test"); // => "test" That's just named arguments to the format. Also, that's a macro; it's expanded at compile time. Python's approach is lame. It should have used something with a limited list of named arguments, or maybe a dict.

Neither does python. The problem being discussed here is that the format string can access and attribute of the object passed in. From PEP3101 [0]: " Unlike some other programming languages, you cannot embed arbitrary expressions in format strings. This is by design - the types of expressions that you can use is deliberately limited. Only two operators are supported: the '.' (getattr) operator, and the '[]' (getitem)…

> don't normally have side effects in non-pathological code

so, "be careful with it if you can't make sure code isn't non-pathological or friendly", what the article says.