GitMate.io thinks possibly related issues are #159 (Make blurb working in Python 3.5.), #153 (blurb uses system python, but expect python 3), #174 (pip install blurb successfully installs with Python < 3.5), #63 (cherry_picker needs Python 3.6), and python/devguide#323 (Mention that building Python docs now requires blurb).

@vstinner @serhiy-storchaka you guys?

I would prefer to keep Python 3.5 support. I don't think that being able to use f-string justify to make development on CPython unusable for people stuck with Python 3.5.

blurb is only used for people contributing to CPython.
If they are contributing to CPython, wouldn't they have Python 3.6+ on their machine?

To write a code patch for cpython master, one must have a cpython clone and should have a local repository build of master to test before submitting. But one can submit without testing, and even if one does have a repository build, blurb (usually) runs on installed python. (At least on Windows.)

Victor is claiming that somewhere in the world there are likely people, I presume on organization machines, who could and would create patches and PRs but have their installed Python locked at 3.5. This is plausible enough to me to defer this issue at this time.

If possible, I would like the repository excludes adjusted so that one could run ensurepip with a repository build and subsequently run pip install with that build and not disturb git's status report. If blurb, cherry-picker, and sphinx were 'well-behaved', this would make patch development independent of PRs independent of installations (for people who can build master). But this would be a different issue.

With PR #288 I've added support for "fake f-strings" to blurb. This gives us something that tastes almost exactly like real f-strings--just with extra parentheses, because f() is a function call.

Blurb development has slowed down greatly. So I expect maintaining this slightly-weird implementation wrinkle for a year or two will add only a negligible maintenance burden. And when we arrive at the glorious future where we can comfortably drop 3.5 support, we can simply remove the parentheses and the definition of f() and we'll be using real f-strings and life will be a dream.

PR #386 dropped support for 3.5 and should have closed this issue.

(Tip: "closes #299, #300, #283" only closes the first issue, you need to repeat the magic "closes" keyword before each issue number.)

See also #419 which proposes dropping 3.6.