[issue38351] Modernize email example from %-formatting to f-string

[Kyle Stanley]

Kyle Stanley <aeros167 at gmail.com> added the comment:

Welcome back from the OOOS break Mariatta!

> My question (and it's just that) is whether we've made a decision to prefer one formatting syntax over others (outside of examples discussing the formatting approaches themselves).

I agree that we should reach a consensus on the preferred string formatting style. However, there seems to be two separate questions here:

1) Should the code examples in the docs be updated to use f-strings?

2) Should ALL instances of the old string formatting be updated to use f-strings? This would affect every *.py; potentially leading to additional code churn, which adds clutter to the commit logs and git blame.

The first one is far less costly and has very minimal risk of breakage. The cost of updating every *.py to use f-strings is worth considering, but is significantly higher and has more potential consequences, especially for the regression tests. I'm personally in favor of updating the code examples first and discussing the second question in a python-dev thread due to the wide impact.

> If a decision is made to prefer one over others, it's worth making that decision separately, and then using separate PRs to deal with updates to different parts of the docs.

Once we reach a decision on the matter, I think this particular issue could serve as a great first PR for a new contributor to become familiar with the workflow, so it would be a good candidate for the "newcomer friendly" label. Most python users are well acquainted with string formatting. I wouldn't mind opening a PR to fix it myself, but I think that leaving it open for a new contributor to work on as an intro to the workflow would be far more beneficial.

Although there may be a benefit to use f-strings instead here, there's certainly no rush to have it completed in a short period of time. I would be in favor of having each PR address a single documentation file. This would help accelerate the review process and provide a valuable learning experience to a greater number of new contributors, in comparison to a single PR that updates every single code example in the docs.

----------
nosy: +aeros167

_______________________________________
Python tracker <report at bugs.python.org>
<https://bugs.python.org/issue38351>
_______________________________________