cherry_picker.py requires Python 3.6

[serhiy-storchaka]

cherry_picker.py uses f-strings and requires Python 3.6. Is this absolutely necessary? The version of Python shipped with Ubuntu LTS (and perhaps other popular distributions) is 3.5.

[Mariatta]

Well... while it's not absolutely necessary, I really like f-strings 😅
It is easy enough to convert the script to be compatible with Python 3.5.

Is this a blocker for you (or others) ?

[serhiy-storchaka]

No, this is not a blocker to me. This shouldn't be large problem since when you use cherry_picker.py you should have built and tested Python in the master branch. But on other hand, when you use just built executable and checkout other branch this can cause problems because py-files in Lib/ no longer match the version of the executable. It would be better to use the system Python.

@ncoghlan, what do you think about this?

[brettcannon]

I see three possible solutions to this:

1. Have a separate checkout for doing the cherry-picking from the interpreter you are using to execute cherry_picker.py (e.g. either a pristine checkout or the one you did the fix in that you pushed upstream; I think git workingtree helps with this)
2. Install Python 3.6.0 manually so you have a permanent install
3. Remove f-strings and add compatibility for Python 3.5

I personally do option 2 although I have done option 1 in the past.

[ncoghlan]

Fedora has multiple runtimes (including 3.6) built as system packages for the benefit of the system python-tox package, so setting up a cpicker venv that uses 3.6 was straightforward for me personally - with the venv active, I get 3.6 when I run python ../core-workflow/cherry_picker/cherry_picker.py ....

Even without a system 3.6 package though, it's possible to do a make altinstall and set up a venv from that with 3.6.x or 3.7.0a0 (I tried making a venv straight from a dev directory, but that confused vex, the venv management utility I use).

I also find it's just plain nice to be able to use the latest features when writing CPython automation tools, and if we assume a venv, we'll be able to consider adding third party dependencies (e.g. @brettcannon's gidgethub library once we start looking at turning this into a fully automated bot)

[brettcannon]

I should also mention that creating a venv from a checkout build works fine (see how make venv works in Docs/), so vex is making some assumption that a checkout build breaks.

[serhiy-storchaka]

I prefer portable tools that don't require creating separate Python installation, but if this is good for other core developers I can use a workaround.

[pitrou]

FWIW, I'd rather have cherry_picker be compatible with recent system Pythons. That includes Python 3.5 or even Python 3.4 on some distributions. I can still install Python 3.6 from Anaconda...

[doko42]

+1 on being compatible with system Pythons