Reopening as RELEASE BLOCKER.

r71936 does indeed install pydoc and idle with a 3 suffix.  However, it 
also removed the 2to3 and smtp.py scripts previously installed by 
setup.py without providing any replacements for them, versioned or not.

Section 25.4.1 of the 3.1 Standard Library docs state "2to3 will usually 
be installed with the Python interpreter as a script. It is also located 
in the Tools/scripts directory of the Python root."

In the case of the OSX installer, as it stands now with r71936, there is 
no longer a 2to3 script in the framework bin directory and Tools/scripts 
is not installed.  So what's a user to do?  Is this also an issue for 
the Windows installers?  What about Linux/Unix distributions?  (For the 
OSX installer, I've also documented the problem in Issue5272).

This raises the issues of what is a sensible way to handle potential 
multiple versions of 2to3. Perhaps this has been discussed and decided 
elsewhere?  If not ...:

I see two scenarios of interest -

1. If a user has installed 2.6 (or newer 2.x), a 2to3 is already 
installed. But installing 3.x will(for 3.0)/should(for 3.1) install a 
3.x 2to3 script.  Should it supersede, co-exist with, or defer to the 
2.x version?

2. If a user is moving from 2.5 or earlier, to 3.x, the 3.x installation 
needs to unconditionally provide 2to3.

In the case of the interpreter, the reason for renaming to python3 is 
clear: python2 and python3 expect different input, produce different 
output, and need to co-exist.  In the case of 2to3, however, there 
shouldn't be any fundamental differences between the versions provided 
with a py2 or a py3 install other than bug fixes and potential new 
features, right?

If so, since the output of 2to3 is python3, one could make the case that 
the py3 installed 2to3 should take precedence over a py2 one, at least 
by default.  If there is the potential need for the user to be able to 
choose which 2to3 to use, then a user-friendly solution would be to have 
py2 and py3 install them as something like 2to3-2 and 2to3-3, 
respectively, and a 2to3 which would prefer 2to3-3 but fall back to 
2to3-2.  Otherwise, the py3k version could always just install as 2to3-3 
and it would be up to the user to know (with documentation help) about 
the potential two versions, since the py2 2to3 version is already out of 
the bag and in the field.  Or the py3 install could unilaterally 
supersede a py2 version, with the limitation that a new 2.6.x (re-
)install would likely cause a 2to3 revert, something that could be fixed 
in 2.7.

In any case, if this hasn't already happened, I think a decision needs 
to be made on how the 2to3 conflict should be handled so that at least 
*one* version of 2to3 is always available, ensuring that the solution 
makes sense for all of the major platforms, and making sure it gets 
implemented *and* properly documented prior to 3.1 release and, if 
necessary, the 2.7 release.

I'm less concerned about the removal of the smtpd.py script as I suspect 
it is little used and I don't know how it is handled by the all of the 
platforms (the OSX installer has provided it in bin up until now).  Does 
the smtpd script even appear in the documentation anywhere?  
Nevertheless, if it hasn't already happened, the impact of its removal 
should be assessed on the major platforms and, if it remains removed, at 
least that should be documented in What's New.