Sure... The issue is still present. To demonstrate the problem:

arch -i386 ./python.exe
Python 3.5.0a0 (default:9b450b19aa11+, Jul 21 2014, 10:03:38) 
[GCC 4.2.1 Compatible Apple LLVM 5.1 (clang-503.0.40)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import sys
>>> sys.maxsize
2147483647
>>> import sysconfig
>>> sysconfig.get_config_var('SIZEOF_LONG')
8
>>> 

This is on a machine that can run 64-bit code and uses a fat binary with i386 and x86_64 support. The script generating _sysconfigdata.py used the x86_64 code and hence created data that's only valid for the x86_64 binary.

It's easy enough to to create a patch that reproduces the preprocessor code in pymacconfig.h in sysconfig.py, but I'm not sure if that is the right fix in particular due to the vagueness of the sysconfig API.  

A short rant:

IMHO the current API of sysconfig is underspecified and tied way to much the arbitrary details of the CPython build system (not the actual function keys, but the set of information that can be retrieved). There is no documentation at all on which keys are present and what there meaning is. As an example, there have been a number of issues in the past where users tried to use the value for key that's only meant to be used at CPython build time and users complained that the value didn't work for them with an installed CPython.