head_lock could be held by another thread when fork happened. We should
reset it to avoid deadlock.

Note: this doesn't unpack f-strings into the underlying JoinedStr AST.

Ideally we'd fully implement JoinedStr here but given its additional
complexity, I think this is worth bandaiding as is. This unblocks tools like
https://github.com/google/yapf to format 3.6 syntax using f-strings.

Defaults to 'no', but as before assertions are implied by --with-pydebug.

This partially solves bpo-23894.

Ran the docstrings through spell checker, and fixed spelling issues.

There was an unneeded space before a closing parenthesis in the `unittest.mock` documentation.

bpo-29619: Do not use HAVE_LARGEFILE_SUPPORT for type conversions (GH-1666).

* Use only the LongLong form for the conversions.

Increases coverage to 99%

* #30014: refactor poll-related classes so that poll(), epoll() and devpoll() share the same methods for register(), unregister(), close() and select()

* remove unused attribute

* use specific class attributes instead of select.* constants

* have all classes except SelectSelector a _selector attribute

* BaseException -> Exception

* be explicit in defining a close() method only for selectors which have it

* fix AttributeError

Based on patches by Duane Griffin and Tim Mitchell.

Original patch by Dennis Mårtensson.

Based on patch by Eryk Sun.

Workaround for a regrtest bug.

* Replaced list(<generator expression>) with list comprehension
* Replaced dict(<generator expression>) with dict comprehension
* Replaced set(<list literal>) with set literal
* Replaced builtin func(<list comprehension>) with func(<generator
  expression>) when supported (e.g. any(), all(), tuple(), min(), &
  max())

If we have a chain of generators/coroutines that are 'yield from'ing
each other, then resuming the stack works like:

- call send() on the outermost generator
- this enters _PyEval_EvalFrameDefault, which re-executes the
  YIELD_FROM opcode
- which calls send() on the next generator
- which enters _PyEval_EvalFrameDefault, which re-executes the
  YIELD_FROM opcode
- ...etc.

However, every time we enter _PyEval_EvalFrameDefault, the first thing
we do is to check for pending signals, and if there are any then we
run the signal handler. And if it raises an exception, then we
immediately propagate that exception *instead* of starting to execute
bytecode. This means that e.g. a SIGINT at the wrong moment can "break
the chain" – it can be raised in the middle of our yield from chain,
with the bottom part of the stack abandoned for the garbage collector.

The fix is pretty simple: there's already a special case in
_PyEval_EvalFrameEx where it skips running signal handlers if the next
opcode is SETUP_FINALLY. (I don't see how this accomplishes anything
useful, but that's another story.) If we extend this check to also
skip running signal handlers when the next opcode is YIELD_FROM, then
that closes the hole – now the exception can only be raised at the
innermost stack frame.

This shouldn't have any performance implications, because the opcode
check happens inside the "slow path" after we've already determined
that there's a pending signal or something similar for us to process;
the vast majority of the time this isn't true and the new check
doesn't run at all.

* Adds lib.pyproj file to solution so that VS with Python support can open all the files in the standard library.

* Remove unexpected solution configuration.

* Remove lib.pyproj from solution to avoid memory issues on VS 2015.

test_is_alive_after_fork() now joins directly the thread to avoid the
following warning added by bpo-30357:

Warning -- threading_cleanup() failed to cleanup 0 threads
after 2 sec (count: 0, dangling: 21)

Use also a different exit code to catch generic exit code 1.

Under  *spawn* and *forkserver* start methods, SimpleQueue.empty() could
raise AttributeError due to not setting _poll in __setstate__.

Before, it was possible to get the following sequence of
events (especially on Windows, where the C-level signal handler for
SIGINT is run in a separate thread):

- SIGINT arrives
- trip_signal is called
- trip_signal writes to the wakeup fd
- the main thread wakes up from select()-or-equivalent
- the main thread checks for pending signals, but doesn't see any
- the main thread drains the wakeup fd
- the main thread goes back to sleep
- trip_signal sets is_tripped=1 and calls Py_AddPendingCall to notify
  the main thread the it should run the Python-level signal handler
- the main thread doesn't notice because it's asleep

This has been causing repeated failures in the Trio test suite:
  https://github.com/python-trio/trio/issues/119

* Use explicit numbering for footnotes referred by explicit number.
* Restore missed footnote reference in stdtypes.rst.
* Fix literal strings formatting in howto/urllib2.rst.
* Update susp-ignored.csv for zipapp.rst.
* Fix suspicious mark up in Misc/NEWS.

Warnings emitted when compile a regular expression now always point
to the line in the user code.  Previously they could point into inners
of the re module if emitted from inside of groups or conditionals.

It should read PYTHONLEGACYWINDOWSSTDIO as stated
in section "Add legacy mode" in PEP 528.