On macOS, the 32 bit python 2.7 reports its architecture as '64bit' in platform.architecture().  Note that the 32 bit Python versions 3.4, 3.5 and 3.6 all correctly report '32bit'.

$ python-32
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 12:39:47) 
[GCC 4.2.1 (Apple Inc. build 5666) (dot 3)] on darwin
Type "help", "copyright", "credits" or "license" for more information.
>>> import platform
>>> platform.architecture()[0]
'64bit'
>>> import sys
>>> sys.maxsize > 2**32
False

platform.architecture() is documented as giving unreliable results with macOS universal files; see https://docs.python.org/2/library/platform.html#platform.architecture.  The difference in behavior between Python 2.7 and 3.x for the example you show is due to the difference in the value of sys.executable between them on macOS.  On 2.7, sys.executable points to the actual Python interpreter binary, which is a universal binary.  On 3.x, the behavior was changed to not to resolve to the interpreter binary but rather the stub launcher binary and the "-32" launcher has only 32-bit executables:

$ /usr/local/bin/python2.7-32 -c 'import sys;print(sys.executable)'
/Library/Frameworks/Python.framework/Versions/2.7/Resources/Python.app/Contents/MacOS/Python
$ /usr/local/bin/python3.6-32 -c 'import sys;print(sys.executable)'
/usr/local/bin/python3.6-32

Because platform.architecture() uses the "file" utility to examine the contents of the file pointed to by sys.executable, this change in 3.x has the side effect of producing the expected "32bit" value on 3.x when Python is invoked in this manner.

However, that doesn't cover all cases.  For example:

$ arch -i386 /usr/local/bin/python3.6 -c 'import sys,platform;print(platform.architecture(), sys.maxsize > 2**32)'
('64bit', '') False

So the 3.x platform.architecture can still produce incorrect results.  One can argue about what value(s) platform.architecture() should return for multi-architecture binaries; languishing Issue10735 covers that.  One could also argue that the value of sys.executable on 2.7 should be changed to behave like 3.x but it's very late in the life of 2.7 to be making a change like that and that change alone would not produce correct results for all cases, like "arch -i386" above.

Thanks for the report, but there really isn't much we can do, since the API is not geared up for handling executables which contain binaries for multiple architectures.

AFAIK, the Python 3 binaries available from python.org are no longer built as universal binaries, so the problem doesn't show with those.

> AFAIK, the Python 3 binaries available from python.org are no longer built as universal binaries, so the problem doesn't show with those.

All python.org Mac binaries are built as universal. For example:

$ file /usr/local/bin/python3.6
/usr/local/bin/python3.6: Mach-O universal binary with 2 architectures: [i386: Mach-O executable i386] [x86_64: Mach-O 64-bit executable x86_64]
/usr/local/bin/python3.6 (for architecture i386):	Mach-O executable i386
/usr/local/bin/python3.6 (for architecture x86_64):	Mach-O 64-bit executable x86_64

Ok, thanks for the clarification. So if I understand correctly, the main change in Python 3 is that points to the stub launcher, not the binary itself.

In any case, a new function would have to be added to the platform module to query multiple architectures available in a binary and probably another one to return the architecture that Python runs.