For 3.3.0, ./configure (configure.ac) was modified in 688d48e434e4 for Issue13590 to use more appropriate defaults for universal builds on newer releases. In particular, --enable-universalsdk=yes uses the Xcode default SDK (as returned by xcodebuild) instead of the 10.4u SDK (not included with Xcode 4), --with-universal-archs now defaults to "intel" if ppc support is not available, and MACOSX_DEPLOYMENT_TARGET defaults to the OS level for 10.6 and newer systems (rather than using 10.4 or 10.3 by default). It also attempts to avoid building Python with deprecated and problematic Apple llvm-gcc compiler, using clang instead.  The defaults can be overridden by providing explicit arguments and/or environment variables to ./configure (--enable-universalsdk, --with-universal-archs, CC, MACOSX_DEPLOYMENT_TARGET).  While not 100% perfect, the 3.3 changes give good defaults for nearly all common universal build configurations on 10.4 through 10.8.

2.7.x and 3.2.x have the same problems; attached are patches that backport the 3.3 configure changes to them.  However, they do introduce a potential incompatibility.  Currently, 2.7 and 3.2 initial configures set MACOSX_DEPLOYMENT_TARGET by default to 10.4 (10.3 on a PPC system) for non-universal builds or 32-bit universal builds and to 10.5 for other universal builds.  For 3.3, those values are still used for 10.4 and 10.5 systems; for 10.6 and later systems, the default deployment target is now the OS level itself (10.6 for builds on 10.6, etc).  Changing the default deployment target for more recent systems has some benefits: the most obvious is that readline support linking with the system BSD libedit is now enabled by default.  The potential incompatibility is that the deployment target value is used by distutils.util.get_platform() to form the platform name which is used for bdist names (like eggs) and the lib build directory for the standard library build.  While I haven't verified that this is the case, if you've built Python 2.7.2, say, from source on 10.6+ and installed some extension modules with Distutils, then would build from a new release with the proposed patches and install to the existing install location without reinstalling the extension modules, there might be a chance of unexpected incompatibilities between the old extension module (built to an older deployment target) and the upgraded interpreter.  Perhaps somewhat more likely is that an extension module binary distribution available on PyPI was available for the old deployment target (10.4) but not for the new target (10.6). Also, it is possible that differences in behavior might be introduced by a change in default compiler.  All of these potential incompatibilities can be avoided by overriding the changed defaults, either at Python build time with arguments to ./configure or at extension module build time with environment variables or Distutils config files.  Introducing such changes is clearly acceptable with a new release, such as 3.3.  For existing releases, it can be argued that the newer, more appropriate settings can also be obtained by just overriding the old defaults ("Explicit is better than implicit.").  The question then is, when the old default behavior no longer makes sense due to changes outside of our control, do the benefits of changing them in a maintenance release outweigh the risk of introducing an incompatibility?

If they are applied, some or all of the changes to the Mac/README file should be backported as well. Also, while working on this, I did find one edge case where the ./configure defaults do not produce a buildable configuration.  The case is on 10.6 with (the optional) Xcode 4.  For universal builds, the test added early in ./configure to determine if ppc is supported doesn't work.  Since the correct compiler hasn't been determined yet, the test looks at the architectures in /usr/lib/libSystem.dylib.  On 10.6, unfortunately, that (and other libs) is a 3-way universal files (i386, x86_64, and ppc) even in the 10.6 SDK supplied with Xcode 4.2 for 10.6 despite the fact that the compilers provided with 4.x do not support building ppc binaries.  The problem shows up right away as the "make" dies quickly and it is easily fixed by specifying --with-universal-archs=intel.  Still, it would be nice to fix that.