parent packages automatically.

Initial patch by Phil Connell.

by multiprocessing.spawn (before it was raising an AttributeError).

"%c" argument is not in range [0; 255].

argument is not in range [0; 255].

In Python 3.3, PyThread_set_key_value() did nothing if the key already exists
(if the current value is a non-NULL pointer).

When _PyGILState_NoteThreadState() is called twice on the same thread with a
different Python thread state, it still keeps the old Python thread state to
keep the old behaviour. Replacing the Python thread state with the new state
introduces new bugs: see issues #10915 and #15751.

Patch written by Vajrasky Kok.

test_capi is failing and the fix is not trivial, I prefer to revert

Patch by Vajrasky Kok, test enhancement by me.

the function did nothing if the key already exists (if the current value is a
non-NULL pointer).

_testcapi.run_in_subinterp() now correctly sets the new Python thread state of
the current thread when a subinterpreter is created.

sometimes busy

Fix a crash when a generator is created in a C thread that is destroyed while
the generator is still used. The issue was that a generator contains a frame,
and the frame kept a reference to the Python state of the destroyed C thread.
The crash occurs when a trace function is setup.

crash when a generator is created in a C thread that is destroyed while the
generator is still used. The issue was that a generator contains a frame, and
the frame kept a reference to the Python state of the destroyed C thread. The
crash occurs when a trace function is setup.

has no concrete GIL. If PyGILState_Ensure() is called from a new thread for the
first time and PyEval_InitThreads() was not called yet, a GIL needs to be
created.

This fixes running test_decimal in verbose mode on Windows,
which I broke in issue #19572.

There are enough new things to make the merge harder than making the
change in VS, and there are other things to add filters for in 3.4.

Also, cleaned up an unused import.

This version of the fix raises an error instead of accepting the invalid
input (ie: if a non-ASCII string is used but no charset is specified).

This is a backward compatible partial fix, the complete fix requires raising
an error instead of accepting the invalid input, so the real fix is only
suitable for 3.4.