Ronald Oussoren added the comment:
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.
----------
stage: -> needs patch
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue17695>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
