Not only are f-strings very programmer friendly, they are also
[https://gist.githubusercontent.com/skabbass1/6afdbbaa2689d2a577b4d76bd77d96a1/raw/6091e9e687aa481b723c3e970ce8091d3f7daa40/fstring_performance.py
very fast] (source: [https://hackernoon.com/a-closer-look-at-how-python-f
-strings-work-f197736b3bdb A Closer Look At How Python f-strings Work]).
--
Ticket URL: <https://code.djangoproject.com/ticket/29988>
Django <https://code.djangoproject.com/>
The Web framework for perfectionists with deadlines.
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:1>
* component: Uncategorized => Core (Other)
* stage: Unreviewed => Someday/Maybe
Comment:
See the [https://groups.google.com/d/topic/django-
developers/psUTrFUNlQE/discussion 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.").
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:2>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:3>
* cc: Tom Forbes (added)
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:4>
* has_patch: 0 => 1
Comment:
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
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:5>
Comment (by 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).
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:6>
Comment (by 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
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:7>
Comment (by 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.
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:8>
* owner: nobody => Carlton Gibson
* status: new => assigned
* stage: Someday/Maybe => Ready for checkin
Comment:
We pushed this forwards after [https://groups.google.com/d/topic/django-
developers/XNhpOHam0zE/discussion discussion on the mailing list].
[https://github.com/django/django/pull/13214 PR]
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:9>
* status: assigned => closed
* resolution: => fixed
Comment:
In [changeset:"411cc0ae18aa9c64447eed229e65e092d23f80e6" 411cc0a]:
{{{
#!CommitTicketReference repository=""
revision="411cc0ae18aa9c64447eed229e65e092d23f80e6"
Fixed #29988 -- Updated coding style to allow f-strings.
Thanks to Nick Pope for review.
}}}
--
Ticket URL: <https://code.djangoproject.com/ticket/29988#comment:10>