Comment 33 for bug 1735363

> Maybe you could add a cmake option to let the user
> select the python binary?

That sounds like a reasonable approach, however I wonder:
* Would you expect the shebang to be adjusted for python3 as well
  (which would require us to configure .py files as a build step
  in this case and seems like a lot of likely unneccessary hassle),
  or would it be fine to call "${python} script.py" from within
  cmake and ignore the shebang?
* I suspect we should also make the binary name that is
  hardcoded into the inkscape binary configurable in this case?
  While possible, I'm a bit afraid it might be unflexible or even
  unpredictable for users:
  Nowadays, they just expect Inkscape to call "python" (so they
  can predict which version of python Inkscape will use by running
  "python --version" from the command line).
  Now we would hardcode any of "python", "python2" or "python3"
  as "default interpreter" with no immediately obvious way for
  users to know which it is.
  Are we sure this would not cause problems in the long run?
  On Windows for example official CPython packages even use
  "python.exe" no matter whether it's Python2 or Python3, so
  at least on this platform I probably wouldn't want to make
  the default call anything else (even if I could make sure the
  bundled Python is called "python3").

> So we have decided long ago to just make the /usr/bin/python symlink
> disappear: that simply removes a whole lot of uncertainties.

Out of curiosity: Is this documented somewhere?
Making packages to call an explicit version because "python" is going to be removed sounds a lot more sane than making packages call "python3" while keeping "python" as an implicit fallback to "python2".
Then again from a general point of view the question is whether it really makes sense to treat Python differently from most other versioned software and hardcode a version number into the executable name to start with. (Nobody would consider directly calling "python3.x", because it would just not be practical either, while 3.x versions are not always API compatible either)