Using Python 3.2.2 and Python 3.3.0a2 (installed via 64-bit installers in official DMGs on python.org), 'distutils.util.get_platform()' returns an incorrect OS version when running on Mac OSX 10.7.

Using Python 2.6.7, and Python 2.7.1 (the versions included with Mac OSX), the output indicates 'macosx-10.7' correctly.

> for version in 2.6 2.7 3.2 3.3; do python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done 2.6.7 macosx-10.7-intel
2.7.1 macosx-10.7-intel
3.2.2 macosx-10.6-intel
3.3.0a2 macosx-10.6-intel

Some packages make use of this in their setup.py to determine the proper location of libraries.

For example, the 'readline' distribution's setup.py does so here: https://github.com/ludwigschwardt/python-readline/blob/6f0e801fa1632fcbb0e005eb9709aaa6051a0f28/setup.py#L33

It fails due to the incorrect assumption that it's running on 10.6 instead of 10.7.  Excerpt from "python setup.py bdist_egg":

building 'readline' extension
Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk
Please check your Xcode installation
gcc-4.2 -fno-strict-aliasing -fno-common -dynamic -DNDEBUG -g -O3 -isysroot /Developer/SDKs/MacOSX10.6.sdk -DHAVE_RL_CALLBACK -DHAVE_RL_CATCH_SIGNAL -DHAVE_RL_COMPLETION_APPEND_CHARACTER -DHAVE_RL_COMPLETION_DISPLAY_MATCHES_HOOK -DHAVE_RL_COMPLETION_MATCHES -DHAVE_RL_COMPLETION_SUPPRESS_APPEND -DHAVE_RL_PRE_INPUT_HOOK -I. -I/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m -c Modules/3.x/readline.c -o build/temp.macosx-10.6-intel-3.2/Modules/3.x/readline.o -Wno-strict-prototypes -isysroot /Developer/SDKs/MacOSX10.6.sdk -arch i386 -arch x86_64
In file included from Modules/3.x/readline.c:8:
/Library/Frameworks/Python.framework/Versions/3.2/include/python3.2m/Python.h:11:20: error: limits.h: No such file or directory

In the cases of both Python 3.x and 2.x, get_platform() is deriving information about the version of OSX from the 'MACOSX_DEPLOYMENT_TARGET' dictionary returned by distutils.sysconfig.get_config_vars().

Using Python 3.2.2:
In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET']
Out[1]: '10.6'

Using Python 2.7.1:
In [1]: import distutils.sysconfig;distutils.sysconfig.get_config_vars()['MACOSX_DEPLOYMENT_TARGET']
Out[1]: '10.7'

While the deployment target seems like a useful source of information, it does not seem to be accurate enough to "Return a string that identifies the current platform" as the docstring for distutils.util.get_platform() suggests.

Interestingly, the 2.x series allowed an os.environ override for the MACOSX_DEPLOYMENT_TARGET value, while the 3.x series did away with that, as a result of http://bugs.python.org/issue9516

> for version in 2.6 2.7 3.2 3.3; do MACOSX_DEPLOYMENT_TARGET=10.42 python${version} -c "from __future__ import print_function;import distutils.util,sys;print(sys.version.split()[0],distutils.util.get_platform())"; done
2.6.7 macosx-10.42-intel
2.7.1 macosx-10.42-intel
3.2.2 macosx-10.6-intel
3.3.0a2 macosx-10.6-intel

For OS X builds, the value returned in get_platform() is not intended to indicate what OS version the Python instance is running on.  Rather, it indicates which ABI version was used to build the Python in use so that Distutils can use the same ABI for building C extension modules.  The ABI is determined by the value of MACOSX_DEPLOYMENT_TARGET at build time.  In this case, a value of "macosx_10.6-intel" means the resulting executables and object files are a universal build with both 32-bit (i386) and 64-bit (x64_64) Intel architectures and can run on Mac OS X 10.6 and higher.  The reason the Apple-supplied system Pythons have a value of 10.7 is that they are built with a deployment target of 10.7; they have no need to run on earlier version of OS X.

The issue with the readline extension build you cite is the error "Compiling with an SDK that doesn't seem to exist: /Developer/SDKs/MacOSX10.6.sdk".  Chances are you are using the most recent Xcode release (4.3.x) from Apple which unfortunately moved the location of the SDKs from /Developer, which now no longer is used by Xcode, to within the Xcode.app bundle itself, now located in /Applications.  A workaround for Xcode 4.3 is to install a symlink to the old location:

sudo ln -s /Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer /Developer

BTW, Issue14499 is now open to track the Xcode 4.3 SDK problem.