Use f-strings for string formatting once support for Python 3.5 is dropped

[Jaap Roes]

The ​end of life date for Python 3.5 is 2020-09-13. This means that the next version of Django after this date (earliest 3.1?) can start using ​Literal String Interpolation (f-strings) for string formatting.

Not only are f-strings very programmer friendly, they are also ​very fast (source: ​A Closer Look At How Python f-strings Work).

[Jaap Roes]

Current master has 193 matches for find . -type f -name "*.py" -exec grep -n "['\"]\.format(" {} + | wc -l. (All direct invocations of the format method on a string literal).

There are 3435 matches for find . -type f -name "*.py" -exec grep -n "['\"] %" {} + | wc -l (All uses of the % operator on a string literal).

There's probably many more places where .format or % formatting is used on a variable string.

EDIT: There's also 435 matches for string concatenation (find . -type f -name "*.py" -exec grep -En "(['\"] \+)|(\+ ['\"])" {} + | wc -l)

[Tim Graham]

See the ​django-developers discussion for some concerns (e.g. no i18n support and Florian's comment, "Knowing what certain members of the core team think about those f-strings, I think there will be first a big discussion if we will allow them at all in Django's codebase.").

[Jaap Roes]

That discussion (and the one linked to) seem to be more about (or digress into) using .format instead of % formatting. I'm not in favor of going through and replacing all % formatting with .format calls. Instead Django should just start using a f-strings feature ("Literal String Interpolation") introduced in Python 3.6 when/where possible.

I'm aware of the concern about i18n, but a lot of the string formatting/concatenation in Django isn't translatable text and therefore isn't affected by that issue at all.

This is really more about replacing code like this:

path=handler.__module__ + '.' + handler.__qualname__, with path=f'{handler.__module__}.{handler.__qualname__}'

return "{}({}, {})".format(self.__class__.__name__, self.sql, self.params) with return f'{self.__class__.__name__}({self.sql}, {self.params})'

and sql = '%s %s%s ON (%s)' % (self.join_type, qn(self.table_name), alias_str, on_clause_sql) with sql = f'{self.join_type} {qn(self.table_name)}{alias_str} ON ({on_clause_sql})'

Which (arguably) benefits the readability and can have a positive performance impact on the Django code base.

[Jon Dufresne]

A first pass that only modifies simple uses of .format() such that the string expressions are shorter, are not translated strings, and do not nest quotes.

​https://github.com/django/django/pull/12650

[Claude Paroz]

I'm in favor of this change. However, I'm a bit hesitant for error messages. They are not translatable now, but they could in the future (and most should IMHO, but this is another story).

[Paolo Melchiorre]

Django 2.2 is the last to support Python 3.5 so I'm in favor of using f-string in Django 3

[Simon Charette]

I am in favor well where it makes sense and has clear readability benefits. I don't have strong rules to provide but I've already seen this feature abused in the wild to compose complex formatting string which makes hard to differentiate placeholders from their delimiters when function calls are involved.

I also share you Claude's concerns about error messages and logging message templates.

[Carlton Gibson]

We pushed this forwards after ​discussion on the mailing list. ​PR

[Carlton Gibson <carlton@…>]

In 411cc0a:

Fixed #29988 -- Updated coding style to allow f-strings.

Thanks to Nick Pope for review.

[Carlton Gibson <carlton.gibson@…>]

In 848e48c:

[3.1.x] Fixed #29988 -- Updated coding style to allow f-strings.

Thanks to Nick Pope for review.

Backport of 411cc0ae18aa9c64447eed229e65e092d23f80e6 from master