of Python (on OSX), and the end result of that is that the combination of
``python-config --ldflags`` and ``python-config --libs`` refers to an actually
existing location.
I've done this in preference to changing python-config to specify
'-framework Python' for linking because that doesn't work when you have multiple
versions of python installed (because '-framework Python' will always link to
the 'Current' version of the framework, without a possibility to specify a
specific version).
clashes with what Python's build target did. Rename the target to 'patchcheck'
to avoid the culture clash.
Closes issue 3758.
Reviewed by Benjamin Peterson.
This patch adds a new configure argument on OSX:
--with-universal-archs=[32-bit|64-bit|all]
When used with the --enable-universalsdk option this controls which
CPU architectures are includes in the framework. The default is 32-bit,
meaning i386 and ppc. The most useful alternative is 'all', which includes
all 4 CPU architectures supported by MacOS X (i386, ppc, x86_64 and ppc64).
This includes limited support for the Carbon bindings in 64-bit mode as well,
limited because (a) I haven't done extensive testing and (b) a large portion
of the Carbon API's aren't available in 64-bit mode anyway.
I've also duplicated a feature of Apple's build of python: setting the
environment variable 'ARCHFLAGS' controls the '-arch' flags used for building
extensions using distutils.
so the tests work when run from an install directory.
They are currently skipped on the daily runs (not from the buildbots)
for checking refleaks, etc.
Adds 'n' as a format specifier for integers, to mirror the same
specifier which is already available for floats. 'n' is the same as
'd', but inserts the current locale-specific thousands grouping.
I added this as a stringlib function, but it's only used by str type,
not unicode. This is because of an implementation detail in
unicode.format(), which does its own str->unicode conversion. But the
unicode version will be needed in 3.0, and it may be needed by other
code eventually in 2.6 (maybe decimal?), so I left it as a stringlib
implementation. As long as the unicode version isn't instantiated,
there's no overhead for this.