constructing infinities. This is done for backwards compatibility
with decimal.py: Infinity coefficients are undefined in _decimal
(in accordance with the specification).

Issue #15895: my analysis was slightly off. The FILE pointer is only leaked when set_main_loader() fails for a pyc file with closeit=0. In the success case run_pyc_file() does its own cleanup of the fp. I've changed the code to use another FILE ptr for pyc files and moved the fclose() to PyRun_SimpleFileExFlags() to make it more obvious what's happening.

Issue #15895: Fix FILE pointer leak in PyRun_SimpleFileExFlags() when filename points to a pyc/pyo file and closeit is false.

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.