- interpreter startup and shutdown code moved to a new
  pylifecycle.c module
- Py_OptimizeFlag moved into the new module with the other
  global flags

Python now uses SipHash24 on all major platforms.

Issue 14673: Add sys.implementation

This introduces a small private API for this common pattern.
The issue has been discovered thanks to Martin's huge-mem buildbot.

Move other various macros to pymcacro.h

Thanks Rusty Russell for having written these amazing C macros!

(following PEP 11).  These systems are systems using Mach C Threads,
SunOS lightweight processes, GNU pth threads and IRIX threads.

 * _Py_fopen() and _Py_stat() come from Python/import.c
 * (_Py)_wrealpath() comes from Python/sysmodule.c
 * _Py_char2wchar(), _Py_wchar2char() and _Py_wfopen() come from Modules/main.c
 * (_Py)_wstat(), (_Py)_wgetcwd(), _Py_wreadlink() come from Modules/getpath.c

Call _wfopen() on Windows, or fopen() otherwise. Return the new file object on
success, or NULL if the file cannot be open or (if PyErr_Occurred()) on unicode
error.

Use stat() or _wstat() depending on the OS.

 * Use _Py_wchar2char() in _wstat() and _Py_wfopen()
 * Document _Py_char2wchar()

at interpreter startup before importing any non-builtin modules.
Should fix #9589.

exposed in Python.h.  This function is similar to POSIX
gettimeofday(struct timeval *tp), but available on platforms without
gettimeofday().

svn+ssh://pythondev@svn.python.org/python/branches/release27-maint

........
  r82969 | stefan.krah | 2010-07-19 15:14:01 +0200 (Mon, 19 Jul 2010) | 14 lines

  Issue #9036: Throughout the code base, Py_CHARMASK is used on 8-bit wide
  signed/unsigned chars or on integers directly derived from those. In all
  cases, it could be replaced by a simple cast to (unsigned char). Reasons
  for the change:

    a) Make the comment more explicit.

    b) If char is unsigned, the cast is optimized away.

    c) If char is unsigned, gcc emits spurious "array subscript
       has type 'char'" warnings.
........

signed/unsigned chars or on integers directly derived from those. In all
cases, it could be replaced by a simple cast to (unsigned char). Reasons
for the change:

  a) Make the comment more explicit.

  b) If char is unsigned, the cast is optimized away.

  c) If char is unsigned, gcc emits spurious "array subscript
     has type 'char'" warnings.

svn+ssh://pythondev@svn.python.org/python/branches/py3k

........
  r82966 | stefan.krah | 2010-07-19 14:36:57 +0200 (Mon, 19 Jul 2010) | 13 lines

  Issue #9036: Throughout the code base, Py_CHARMASK is used on 8-bit wide
  signed/unsigned chars or on integers directly derived from those. In all
  cases, it could be replaced by a simple cast to (unsigned char). Reasons
  for the change:

    a) Make the comment more explicit.

    b) If char is unsigned, the cast is optimized away.

    c) If char is unsigned, gcc emits spurious "array subscript
       has type 'char'" warnings.
........

signed/unsigned chars or on integers directly derived from those. In all
cases, it could be replaced by a simple cast to (unsigned char). Reasons
for the change:

  a) Make the comment more explicit.

  b) If char is unsigned, the cast is optimized away.

  c) If char is unsigned, gcc emits spurious "array subscript
     has type 'char'" warnings.

http://code.google.com/p/data-race-test/wiki/ThreadSanitizer is a dynamic data
race detector that runs on top of valgrind. With this patch, the binaries at
http://code.google.com/p/data-race-test/wiki/ThreadSanitizer#Binaries pass many
but not all of the Python tests. All of regrtest still passes outside of tsan.

I've implemented part of the C1x atomic types so that we can explicitly mark
variables that are used across threads, and get defined behavior as compilers
advance.

I've added tsan's client header and implementation to the codebase in
dynamic_annotations.{h,c} (docs at
http://code.google.com/p/data-race-test/wiki/DynamicAnnotations).
Unfortunately, I haven't been able to get helgrind and drd to give sensible
error messages, even when I use their client annotations, so I'm not supporting
them.

This fixes issue #8441: python.c is not included
in the framework while main.c is and without this
patch you get a link error when building
Python.framework on OSX.

CObject to PyCapsule.

Add the Python/dtoa.c file containing the main algorithms;
add corresponding include file and include in Python.h;
include license information for Python/dtoa.c;
add dtoa.c and dtoa.h to Makefile.

Issue 7147 - remove ability to attempt to build Python without complex number support (was broken anyway)

All stdlib modules with C-APIs now use this.

Patch by Larry Hastings

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r72040 | eric.smith | 2009-04-27 15:04:37 -0400 (Mon, 27 Apr 2009) | 1 line

  Issue #5793: rationalize isdigit / isalpha / tolower, etc. Will port to py3k. Should fix Windows buildbot errors.
........

Issue #5793: rationalize isdigit / isalpha / tolower, etc. Will port to py3k. Should fix Windows buildbot errors.

 - incorporate and adapt David Gay's dtoa and strtod
   into the Python core
 - on platforms where we can use Gay's code (almost
   all!), repr(float) is based on the shortest
   sequence of decimal digits that rounds correctly.
 - add sys.float_repr_style attribute to indicate
   whether we're using Gay's code or not
 - add autoconf magic to detect and enable SSE2
   instructions on x86/gcc
 - slight change to repr and str:  repr switches
   to exponential notation at 1e16 instead of
   1e17, str switches at 1e11 instead of 1e12

svn+ssh://pythondev@svn.python.org/python/trunk

........
  r63955 | ronald.oussoren | 2008-06-05 14:58:24 +0200 (Thu, 05 Jun 2008) | 20 lines

  MacOS X: Enable 4-way universal builds

  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.
........