they are created in the install locations and with the proper timestamp.
(Solution suggested by MvL)

sporadic crashes in multi-thread programs when several long deallocator
chains ran concurrently and involved subclasses of built-in container
types.

Because of this change, a couple extension modules compiled for 3.2.4
(those which use the trashcan mechanism, despite it being undocumented)
will not be loadable by 3.2.3 and earlier. However, extension modules
compiled for 3.2.3 and earlier will be loadable by 3.2.4.

Fix window.addch() of the curses module for special characters like
curses.ACS_HLINE: the Python function addch(int) and addch(bytes) is now
calling the C function waddch()/mvwaddch() (as it was done in Python 3.2),
instead of wadd_wch()/mvwadd_wch(). The Python function addch(str) is still
calling the C function wadd_wch()/mvwadd_wch() if the Python curses is linked
to libncursesw.

return one.

This was a regression caused by the hash randomization patch.

errno error numbers and Windows error numbers.

character for most keys, and an integer for special keys, instead of always
returning an integer. So it is now possible to distinguish special keys like
keypad keys.

  compiled using the clang compiler

(merge from 3.2)

Fix issue 13370: Ensure that ctypes works on Mac OS X when Python is compiled using the clang compiler

fromlist of __import__ propagate.

The problem previously was that if something listed in fromlist didn't
exist then that's okay. The fix for that was too broad in terms of
catching ImportError.

The trick with the solution to this issue is that the proper
refactoring of import thanks to importlib doesn't allow for a way to
distinguish (portably) between an ImportError because finders couldn't
find a loader, or a loader raised the exception. In Python 3.4 the
hope is to introduce a new exception (e.g. ModuleNotFound) to make it
clean to differentiate why ImportError was raised.

will be removed in Python 4.0.