An instance of the shell script "Update Shell Profile.command"
         is installed in each "/Applications/Python x.x" folder.
         Clicking on the script allows the user to change the default
         Python version.  If the scripts are run more than once - say
         first to make 3.0 the default then 2.6 the default then back
         to 3.0 again - the script will fail to update the user's $PATH,
         forcing users to manually edit their shell profile.

SOLUTION Ensure that $PATH is updated if there are other Python
         frameworks already on its head.

         (This is not the most elegant solution since it leaves the
         previous versions later in the path but it is safer to
         only append to the user's profile - and a backup copy
         is made.)

APPLIES  py3k, 3.0, trunk, 2.6

I don't like this patch because it could grow the users profile without 
bounds when switching back and forth between two python versions.

I agree the patch is not a good solution but it is relatively safe.  I 
suppose the current buggy behavior of Update Shell Profile *does* limit 
the growth to the number of Python versions you've installed.  However the 
patch does allow users not comfortable with shell scripts to move between 
versions.  On the other hand, they can always use the various IDLEs.  This 
whole area of PATH manipulation and symlinks for OS X could use a good re-
thinking; a lot of cruft has accumulated over the years and it gets worse 
with 4-way builds.

I agree that we need a better solution to select which version of Python 
is the default one of your path.

One way to do that is to have a tool that can change the "Current" link 
inside the framework, that way we could have 
/Library/Frameworks/Python.framework/Version/Current/bin early on $PATH 
and add the various version directories after that.

I'd also like to see a per-user way to change the default python without 
manually editing the shell profile.

W.r.t. to the myriad of other variations in a 4-way universal build: 
those are necessary to ensure that you can easily force the use of a 32-
bit or 64-bit build because at the time a lot of GUI code required 32-
bit code. I hope this will change over time, I'd love to have a much 
simpler framework that contains only a single copy of the python 
executable instead of the 3 variants that are currently present in a 4-
way universal build.