The Windows installer gives a choice of two install locations, for all users and for the current user; the latter does not require admin rights.  

It lists optional components, giving the size of each:
- Register Extensions 2kb
- Tcl/Tk 13mb (includes IDLE)
- Documentation 5Mb
- Utility Scripts 632kb
- Test Suite 9.7Mb.  
The default is to install all of those.

The installer removes any previous versions before installing (including wiping their __pycache__ directories).

With the full install, the listing in All Programs (the windows parallel to the Application Folder) includes five entries:
- IDLE (gui)
- Module Docs (via pydoc)
- Python (command-line terminal)
- Python Manuals (points to a chm file)
- Uninstall Python.

In addition to what is offered on Windows, I think there should be an addition entry in the Application Folder for running the test suite so that some one can validate their install without going to the command-line.

I'm +1 on the general idea, but have some remarks anyway:

1) "for all users" vs. "current user"

This likely requires a post-install script to fix up the load command's in binaries: on OSX binaries contain absolute paths to the libraries the link with (which for the binary installers includes libpython). This is easy to do with macholib, but that's not in the stdlib.

An alternative is to use @loader_path, to link with a path relative to the executable, but that would mean you can no longer copy the python binary an expect it to work (which currently does work for framework installs)

2) Tcl/Tk: this is currently not included in the binary installer, although it might be better to start doing that given the problems described in <http://www.python.org/download/mac/tcltk/>. The disadvantage is that the size of the installer would grow significantly.

3) A pre-install hook that cleans up previous installations of the same feature release would be nice, currently upgrade can keep junk files alive.

4) We're already installing IDLE and the Python documentation in the Application folder (as well as the mac-specific Python Launcher and a tool for updating the command-line shell profile). Adding a link for starting the command-line in Terminal.app is a good idea.

5) I'm not sure about an uninstall option, while it would be nice to
have such an option it would also be custom code that runs with increased privileges (for the "all users" install). Sadly enough Apple doesn't have an uninstall option in their packaging solution.

BTW. There is a completely different way for distributing Python: drop the entire installer and provide a zipfile containing a single application bundle.

The most likely target for the application is IDLE, with a new menu item for making the command-line tools available (see editors like Textmate and BBEdit for a precedent, or even Xcode).

The advantage of a single application bundle is that you don't have to have an installer, users can just drag&drop for installation *and deinstallation*. An added advantage is that there are third party
libraries that make it easy to (auto-)update applications, the 
"check for updates" menu in a lot of Mac apps is based on an opensource
library that could be used here is well.

There are some disadvatages as well:

* It is different than how Python is currently distributed, any
  change will upset some people

* If there's a single application bundle you cannot easily add
  Python Launcher (although it could be hidden inside the toplevel app)

* At least some people will be upset by having to start IDLE at all,
  even if it would only be used to make the command-line tools available

* Someone will have to do the work :-)

I intentionally don't list the Mac App store as an advantage or disadvantage, primarily because the app store requires sandboxing and that would make no sense for a general programming tool (a sandboxed version of IDLE app could be used to start scripts, but those scripts would be in the sandbox as well and hence couldn't access most of the system).