"#!/usr/bin/env bash" or "#!/usr/bin/env python" are the recommended ways to run both, AFAIK.
Sometimes I used to create such a symlink myself but I don't use or run a lot of python day to day so my current systems do not have this.
Most (all?) commercial Unix I have used also don't have bash, but those systems are pretty dead these days.
OpenBSD's fork of ksh is actually really good so I typically feel no reason to ever install bash on there. On others, the default shell kinda sucks and I tend to install bash. In particular the old /bin/sh on older Unix tends to be worse at interactive use and not support some constructs like {a,b}
I'm typing this on FreeBSD. It's in /usr/local because it came from ports.
$ which bash
/usr/local/bin/bash
$ which bash
which: bash: Command not found.Why would you expect it to be?
dash is a POSIX shell:
* https://en.wikipedia.org/wiki/Almquist_shell#dash
Even when called as /bin/sh, which implies Bourne/POSIX behaviour, bash leaks all kinds of functionality into the environment such that if you tru to run your "/bin/sh" script on another shell it may not work.
We had all sorts of issues when Debian made the switch: we had to tell people either (a) fix the code, or (b) change your shebang to bash.
If you want Bash behaviour call bash. It's like when I type in "vi" in the command line and I get an editor with all sorts of colours: WTF? If I wanted Vim I would have typed in "vim", but for editing a small file all I need is POSIX vi without the dog and pony display show. /rant
So do /bin/sh and /bin/bash scripts.
/usr/bin/python scripts IME depend on what /usr/bin/python points to; some break/broke due to the python 2 to python 3 switching, which hasn't been as backwards-compatible as previous examples have.