Live data from Hacker News

Be Careful with Python's New-Style String Format

lucumr.pocoo.org

21–30 of 155 posts

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

#21
post #16
post #11

Earlier quoted context omitted.

Internationalization, usually. Word order differs between languages, and this kind of format allows reordering the inserted values.

Yes, but that's meant for trusted translators of the UI, nor arbitrary users, right?

In some applications, users can change the their own translations, which are stored in the DB, to allow for easier customization.

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

#22
post #18

Earlier quoted context omitted.

"Customize the look of your blog by editing these templates."

Shouldn't that be based not on the built-in string capabilities, but on a template engine, that must also take care for much more narrow cases of abuse (e.g. SQL injection, or access to only of a restricted number of helper functions within the template)?

Many templates allow accessing fields. There's no risk of SQL injection, you're only echoing the output back to the user.

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

#23
post #14

Until now I thought the new features were confined to `f""` format strings. Edit: As correctly pointed out, this feature has been around since the introduction of str.format(). So this warning applies to all Python versions.

This is not a new feature.

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

#24
post #18

Earlier quoted context omitted.

"Customize the look of your blog by editing these templates."

Shouldn't that be based not on the built-in string capabilities, but on a template engine, that must also take care for much more narrow cases of abuse (e.g. SQL injection, or access to only of a restricted number of helper functions within the template)?

The author discovered this exploit in the template engine he wrote (Jinja2).

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

#25
post #14

Until now I thought the new features were confined to `f""` format strings. Edit: As correctly pointed out, this feature has been around since the introduction of str.format(). So this warning applies to all Python versions.

This is not a new feature.

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

#26
post #14

Until now I thought the new features were confined to `f""` format strings. Edit: As correctly pointed out, this feature has been around since the introduction of str.format(). So this warning applies to all Python versions.

This existed in python 2.6; it's not a new feature by any means.

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

#27
post #20
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.

Also, in C# the string interpolation works only on literal strings at compile time. So it's not possible to inject a malicious code this way from outside of the source code.

So does in Python. This isn't string interpolation, it's the equivalent of String.Format.

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

#30
This is actually a problem with a lot of languages that allow runtime template like String interpolation.

For example Groovy on the JVM has GStrings which one can do fairly nasty things.

As well it actually is fairly hard to lock down most of the template languages on the JVM for user templates. (If you are going to allow user templates I recommend one of the Java Mustache-like implementations).

Post reply on HN