On the python-dev mailing list, Raymond Hettinger asks:
> I was exercising the alpha two release of 3.4 and noticed that
> it is still being built under GCC 4.2.1.  
> 
> Is there any reason we have to use an old compiler?

Yes, kinda.  It's because the 64-bit/32-bit installer we supply is designed to run on multiple versions of OS X: 10.6 (Snow Leopard), 10.7, 10.8, and the upcoming 10.9.  The safest way to ensure that the bits produced (executables, shared libs, and .so bundles) are linked with compatible versions of system shared libraries and frameworks is to build on the lowest supported system, 10.6, or - carefully - with a 10.6 SDK on a newer system.  The standard compiler in the Apple Developer Tools for 10.6 is gcc 4.2.  The most recent Developer Tools for 10.8 and 10.7 systems, Xcode 4.6.x, have a mature clang but do not provide a 10.6 SDK.  Even with using an SDK, it's still possible to end up inadvertently linking with the wrong versions of system libraries.  We have been burned by that in the past.

> I would like to see it built under the latest version of Clang
> (like the other tools on the Mac) or under GCC 4.8.1.
> I've better using the latter for many months.  It works great
> and produces *much* better code (in terms of readability
> for those of us who look at assembly output and in terms
> of speed (approx 20-25% better for cpu bound code)).
> 
> I'm wondering whether is some issue that forces us to use
> GCC 4.2.1 or whether that is just an artifact of continuing
> to do what we've always been doing.

I'd like to move to Apple's latest clang, as well.  (Apple is dropping gcc totally from the next release of Xcode.)  There are a couple of approaches that may work and still reliably support multiple versions of OS X.  Investigating this is on my list of things to do prior to the next alpha.