This issue tracker has been migrated to GitHub, and is currently read-only.
For more information, see the GitHub FAQs in the Python's Developer Guide.

Author aeros
Recipients JulienPalard, Mariatta, aeros, docs@python, fdrake
Date 2019-10-03.00:06:07
SpamBayes Score -1.0
Marked as misclassified Yes
Message-id <>
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.
Date User Action Args
2019-10-03 00:06:08aerossetrecipients: + aeros, fdrake, docs@python, JulienPalard, Mariatta
2019-10-03 00:06:08aerossetmessageid: <>
2019-10-03 00:06:08aeroslinkissue38351 messages
2019-10-03 00:06:07aeroscreate