LWN: Comments on "Easier Python string formatting"

Easier Python string formatting

Cyberax — Tue, 22 Sep 2015 17:14:59 +0000

Uhm, how? You still have to encode/decode incoming data.

Easier Python string formatting

MKesper — Tue, 22 Sep 2015 10:42:02 +0000

decode() and .encode() clutter is what I remove when converting from Py2 to Py3.

Easier Python string formatting

Rynor — Thu, 17 Sep 2015 07:59:41 +0000

This is just silly and so contradictory to the Zen of Python.
I'd say .format() already handles all the required functionality in a concise way.

"Explicit is better than implicit."
Using variables from the local and global scope is just asking for unclear code.

"There should be one-- and preferably only one --obvious way to do it."
As said before, there are already too many alternatives. Why add another that just duplicates functionality?

And finally..
"Special cases aren't special enough to break the rules."

Easier Python string formatting

epa — Mon, 14 Sep 2015 08:38:58 +0000

Many 'proper placeholder systems' end up working by string interpolation in the end (I am thinking of DBMSes which don't have a separate wire protocol for declaring and setting placeholders). As long as the interpolation is done sanely and with knowledge of the proper syntax rules, what's the problem?

Easier Python string formatting

Cyberax — Fri, 11 Sep 2015 21:49:26 +0000

I guess the same way. You just don't need to specify all the inputs in the .format() part.

Actually, a couple of years back, I had a helper that used "locals()" method to get all the in-scope variables for the format() call.

Easier Python string formatting

mgedmin — Fri, 11 Sep 2015 21:01:51 +0000

This raises a good point. I know that

_("Today is {day} {month}").format(...)

works. How will you translate f-strings?

Easier Python string formatting

jezuch — Fri, 11 Sep 2015 11:53:27 +0000

> i'The answer is {answer}'
>
> There is a key difference, though: while f-strings produce a formatted string immediately on execution, i-strings delay that formatting. An explicit call to a format function is required to do the job.

Groan. It's not fixing the insecurity, it's delaying the insecurity. Either use proper placeholder system (whatever it is in your language/library) or go back to PHP :)

Easier Python string formatting

vapier — Thu, 10 Sep 2015 23:36:12 +0000

i don't generally consider them the same since they have different syntax. these are not equiv:

d = {'answer': 1}
'The answer = {answer}'.format(**answer)
'The answer = %(answer)d' % answer

the first form has to be:

'The answer = {answer!d}'.format(**answer)

and the python team themselves document them in completely different sections:

https://docs.python.org/2/library/stdtypes.html#string-fo...
https://docs.python.org/2/library/string.html#format-stri...

Easier Python string formatting

flussence — Thu, 10 Sep 2015 22:42:22 +0000

That snide jab at Perl at the end is heavily ironic. Python's newly added «f""» modifier is identical in function and syntax to Perl 6's «q:c""», which predates it by several years. The only real difference is in implementation: Python's is hardcoded into the language, whereas Perl's is extensible and allows user-defined constructs (say, «q:sql""»).

(«i""» sounds like a 1:1 copy of Javascript's template strings, FWIW.)

Easier Python string formatting

maney — Thu, 10 Sep 2015 22:25:52 +0000

There's "explicit is better than implicit", though I would agree that that's more of a guideline than a rule. But my immediate reaction from partway through the article, as shared in #chipy, looked like this:

There should be one obviously correct way to do things. Except for string formatting, where three is okay, but four would be better.

Easier Python string formatting

Cyberax — Thu, 10 Sep 2015 22:08:59 +0000

However, let's consider this:

"Today is {} {}".format(month, date)

Now, let's add some localization:

"Heute ist {} {}".format(date, month)

See the difference? String interpolation is a very useful tool.

Easier Python string formatting

corbet — Thu, 10 Sep 2015 21:38:28 +0000

Whatever. I would posit that

    'The answer is {}'.format(answer)

is still more verbose than:

    f'The answer is {answer}'

The people working on this facility would seem to agree. But a couple of folks have said this now, so perhaps this feeling isn't universal?

Easier Python string formatting

Fats — Thu, 10 Sep 2015 21:24:08 +0000

But your .format() example then really looks as verbose on purpose.
You could also do:

    'The answer is {}'.format(42)

Easier Python string formatting

josh — Thu, 10 Sep 2015 17:28:21 +0000

> The format() string method is more flexible, but is somewhat verbose

.format() doesn't need to be any more verbose than the % operator, if you don't use names:

'The answer = {}'.format(42)

Easier Python string formatting

dashesy — Thu, 10 Sep 2015 17:04:05 +0000

There are already plenitude of excellent template magic in Python, like Jinja and django has its own. Why is the language bothering with providing an (unavoidably) inferior solution to what is just a `pip install` away. The best way to do `foo()` in Python is this:

pip install foo_bar

then

from foo_bar import foo
foo()

As if it is not already annoying in one code-base to see strings with single(`), or double(") or tiple(""") quotes (I know PEP discourages some forms), along with b or r or u and now f too! Scattered with `.decode(..)` and `.encode(..)` clutter to make Py3 happy.

Easier Python string formatting

talex — Thu, 10 Sep 2015 16:07:06 +0000

A similar system is used in E, except that rather than escaping bad characters, it typically creates a structured object instead of a string. Consider this E code:

def name := "O'No! $@?"
sql`INSERT INTO users (userName, karma) VALUES ($name, 0)`

Here, the template is first parsed as an SQL prepared statement, then the arguments are filled in. There's nothing special about the "sql" prefix. The E parser expands this to:

sql__quasiParser.valueMaker("INSERT INTO users (userName, karma) VALUES (${0}, 0)").substitute([name])

sql__quasiParser is an ordinary object (in this case, the result of opening a database connection). By creating objects with such names, any prefix can be defined. Similar parsers can be used for XML, regular expressions, JSON, etc.

There's no risk of using plain string interpolation by mistake, because something that wants XML will expect an XML element, not a string.

See: http://wiki.erights.org/wiki/Walnut/Ordinary_Programming/...

Easier Python string formatting

corbet — Thu, 10 Sep 2015 14:45:03 +0000

I had just grouped that in as a use of the % operator — didn't want to get into all of the details of it. Especially if you start to get into "%locals()" and other dirty tricks like that...

Easier Python string formatting

richmoore — Thu, 10 Sep 2015 14:03:32 +0000

There's another existing way too:

'the answer is %(answer)s' % ({'answer': 42})