Bump minimum python version to 3.6

[ajtowns]

Python 3.5 has reached end-of-life as of September 2020, and 3.6 has some moderately nice features:

• f'x = {x}' as an alternative to 'x = {}'.format(x) format strings (cf docs: Specify preferred Python string formatting technique #13718 (comment))
• underscore separators for large numbers, like 1_234_567
• improvements to async
• improvements to typing module

Note that 3.6 is not available in xenial (16.04), but is available in bionic (18.04), while focal (20.04) has 3.8. CentOS 7 and 8 have 3.6.8, Debian stable has 3.7.3, and gentoo and arch already had 3.6 and 3.7 in 2018.

[maflcko]

review ACK, but I am not sure if we need to push this into the upcoming release. Is there any reason this can't wait 3.5 months? While xenial has a c++17 compiler, but lacks a c++17 compatible stdlib, xenial will die anyway. No strong opinion, though.

Might need to update the travis yaml python linter version?

[DrahtBot]

The following sections might be updated with supplementary metadata relevant to reviewers and maintainers.

Conflicts

Reviewers, this pull request conflicts with the following ones:

• ci: Run ci configs on cirrus #19179 (ci: Run ci configs on cirrus by MarcoFalke)

If you consider this pull request important, please also help to review the conflicting pull requests. Ideally, start with the one that should be merged first.

[ajtowns]

No objection to letting it wait; mostly just thought it made more sense to do a PR directly than open a "python 3.5 is nearing eol" issue.

[practicalswift]

Concept ACK: alive is better than end-of-life

[maflcko]

Assigned 0.22.0 milestone with proposed merge date of Nov 1st.

If python 3.6 is needed to simplify mypy, then it can be merged sooner #19389 (comment)

[jnewbery]

Concept ACK

[Sjors]

Concept ACK. No strong preference on when, but having it coincide with our C++17 bump makes sense.

[laanwj]

I like Python 3.6's improvements a lot,1 concept ACK if/when the Linux distributions we support building on have it.

[troygiorshev]

Concept ACK

If python 3.6 is needed to simplify mypy, then it can be merged sooner #19389 (comment)

From what I can tell right now, I don't think this will be the case. I think we'll be ok with 3.5.

[fjahr]

tested ACK 2b53176

Agree this can wait a bit and be done with c++17.

[fanquake]

Concept ACK. No mention of 3.6+ related typing improvements in the op, which is probably what I'm most interested in. I wouldn't be overly concerned about CentOS 7 or Xenial support here.

[theStack]

Strong concept ACK (no need to rush though, as others already stated doing this along with the C++17 bump seems reasonable).

[kristapsk]

Concept ACK

[maflcko]

@ajtowns Are you still working on this? Would be good to rebase and address the feedback

[Sjors]

tACK ef0b760 on macOS 10.15.7

[kristapsk]

• Use f'{x}' for string formatting in preference to '{}'.format(x) or '%s' % x.

This PR changes this in test/functional/feature_block.py, but there are other places where .format is still used, shouldn't it be changed everywhere then?

Also, maybe some linter script could be added that checks .py files for this?

But probably that's out of scope of this PR and can be done in follow-up PR(s).

[ajtowns]

• Use f'{x}' for string formatting in preference to '{}'.format(x) or '%s' % x.

This PR changes this in test/functional/feature_block.py, but there are other places where .format is still used, shouldn't it be changed everywhere then?

It's changed there so that CI tests that it works (eg, failing if an older version of python is being used) and as an example for what the style looks like. General policy is to update code to new style guidelines only when the code is touched for other reasons, so really even doing that is pushing it :)

[practicalswift]

ACK modulo fix for CI failure :)

[maflcko]

ACK 9bc4cdf

for 0.22

[maflcko]

re-ACK 97c738f

for 22.0
only change is rebase