* bpo-36260: Add pitfalls to zipfile module documentation
We saw vulnerability warning description (including zip bomb) in Doc/library/xml.rst file.
This gave us the idea of documentation improvement.
So, we moved a little bit forward :P
And the doc patch can be found (pr).
* fix trailing whitespace
* 📜🤖 Added by blurb_it.
* Reformat text for consistency.
Before, running deactivate from a bash shell configured to treat undefined variables as errors (`set -u`) would produce a warning:
```
$ python3 -m venv test
$ source test/bin/activate
(test) $ deactivate
-bash: $1: unbound variable
```
* bpo-37972: unittest.mock._Call now passes on __getitem__ to the __getattr__ chaining so that call() can be subscriptable
* 📜🤖 Added by blurb_it.
* Update 2019-08-28-21-40-12.bpo-37972.kP-n4L.rst
added name of the contributor
* bpo-37972: made all dunder methods chainable for _Call
* bpo-37972: delegate only attributes of tuple instead to __getattr__
* bpo-20504 : in cgi.py, fix bug when a multipart/form-data request has no content-length header
* Add Misc/NEWS.d/next file.
* Add rst formatting for NEWS.d/next file
* Reaplce assert by self.assertEqual
* bpo-35168: Documentation about shlex.punctuation_chars now states that it should be set in __init__.py
* bpo-35168: Convert shlex.punctuation_chars to read-only property
* Add NEWS.d entry
* Document `unittest.IsolatedAsyncioTestCase` API
* Add a simple example with respect to order of evaluation of setup and teardown calls.
https://bugs.python.org/issue32972
Automerge-Triggered-By: @asvetlov
bpo-37151: remove special case for PyCFunction from PyObject_Call
Alse, make the undocumented function PyCFunction_Call an alias
of PyObject_Call and deprecate it.
Different libc implementations have different behavior when presented with trailing % in strftime strings. To make test_strftime_trailing_percent more portable, compare the output of datetime.strftime directly to that of time.strftime rather than hardcoding.
Relative imports use resolve_name to get the absolute target name,
which first seeks the current module's absolute package name from the globals:
If __package__ (and __spec__.parent) are missing then
import uses __name__, truncating the last segment if
the module is a submodule rather than a package __init__.py
(which it guesses from whether __path__ is defined).
The __name__ attempt should fail if there is no parent package (top level modules),
if __name__ is '__main__' (-m entry points), or both (scripts).
That is, if both __name__ has no subcomponents and the module does not seem
to be a package __init__ module then import should fail.