The main reason why it's a good idea to use the /usr/bin/env approach is that not everyone has python installed in the same place -- sometimes it's in /usr/bin, sometimes it's in /usr/local/bin or /opt/local/bin, sometimes you have to install your own copy in your home directory, etc.
If you use the /usr/bin/env version then it will find the python executable by looking in your path, so all you have to do is update your .profile or other appropriate startup scripts to include the appropriate directory in your path and your scripts will work everywhere without modification.
If you hardcode the path as /usr/bin/python and then move the script to a machine where it is installed in /usr/local/bin (or send the script to someone that has it installed there), you'll have to edit the script to get it to work.
Obviously this is more important if you are distributing your scripts to the public or a large group of people with different environments but it can be helpful even if the scripts are just for you. For example, I have both regular python and stackless python installed on the same machine and I need to run some things in one environment and some in the other, so I have aliases set up that change my path to point to the appropriate interpreter. If I used the hardcoded approach I wouldn't get the right interpreter automatically.
Comment
The main reason why it's a good idea to use the /usr/bin/env approach is that not everyone has python installed in the same place -- sometimes it's in /usr/bin, sometimes it's in /usr/local/bin or /opt/local/bin, sometimes you have to install your own copy in your home directory, etc.
If you use the /usr/bin/env version then it will find the python executable by looking in your path, so all you have to do is update your .profile or other appropriate startup scripts to include the appropriate directory in your path and your scripts will work everywhere without modification.
If you hardcode the path as /usr/bin/python and then move the script to a machine where it is installed in /usr/local/bin (or send the script to someone that has it installed there), you'll have to edit the script to get it to work.
Obviously this is more important if you are distributing your scripts to the public or a large group of people with different environments but it can be helpful even if the scripts are just for you. For example, I have both regular python and stackless python installed on the same machine and I need to run some things in one environment and some in the other, so I have aliases set up that change my path to point to the appropriate interpreter. If I used the hardcoded approach I wouldn't get the right interpreter automatically.