Survey of different mechanisms for running Python to generate files:

Tools/scripts/generate_opcode_h.py and Parser/asdl_c.py: configure.ac tries python3.6, python3, python, etc commands. It either runs the scripts with what it finds, or substitutes an “echo” command that emits an explanation but does not fail. One disadvantage of this was it needed a script to be made compatible with Python 2.5 <https://bugs.python.org/issue17861#msg217409>.

Python/makeopcodetargets.py: Always run as a Unix command with shebang “#! /usr/bin/env python”.

Objects/typeslots.py: Always run via $(PYTHON) command, which defaults to “python$(EXE)”. No magic configure stuff, but could be manually adjusted by using “make PYTHON=[. . .]”. This is the only remaining use of the $(PYTHON) makefile variable in 3.6, but it is shared with other stuff in 2.7.

An idea I had a while ago was to only run these scripts with a special Make command, eliminating the need for “make touch”. Going over a discussion earlier this year, Nick Coghlan <http://article.gmane.org/gmane.comp.python.devel/156682> said a disadvantage of this is that you have to remember the special Make command to use in the rare event that your work affects a generated. Maybe this could be overcome with documentation, warning messages, etc. Argument Clinic code and the configure script are not automatically regenerated.

Another potential idea is a flag (either to configure, or to Make) to manually disable or enable all running of Python scripts. When disabled, it would use the existing generated files, and perhaps warn if they are out of date. Or by default perhaps the warning could be an error, with the resolution to either tell it to use a pre-installed Python, or explicitly run the build with the existing generated files.