* 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.
(cherry picked from commit 3ba51d587f)
Co-authored-by: JunWei Song <sungboss2004@gmail.com>
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
```
(cherry picked from commit 5209e586b7)
Co-authored-by: Daniel Abrahamsson <hamsson@gmail.com>
Since they have been removed from cgi it's useful to remind people where they
can be found instead.
(cherry picked from commit 1abf54336f)
Co-authored-by: Simon Willison <swillison@gmail.com>
* bpo-36919: make test_issue2301 implementation-independent
(cherry picked from commit b6643dcfc2)
Co-authored-by: Pavel Koneski <pavel.koneski@gmail.com>
* bpo-34519: Add additional aliases for HP Roman 8
HP Roman 8 is known under mode aliases than listed in aliases.py.
Patch by Michael Osipov.
(cherry picked from commit a828514cc3)
Co-authored-by: Michael Osipov <michael.osipov@siemens.com>
* 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
(cherry picked from commit 2d7cacacc3)
Co-authored-by: Pierre Quentel <pierre.quentel@gmail.com>
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.
(cherry picked from commit f2173ae38f)
Co-authored-by: Benjamin Peterson <benjamin@python.org>
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..
(cherry picked from commit 92420b3e67)
Co-authored-by: Ben Lewis <benjimin@users.noreply.github.com>
* 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
(cherry picked from commit 6a9fd66f6e)
Co-authored-by: Xtreak <tir.karthi@gmail.com>
A root cause of bpo-37936 is that it's easy to write a .gitignore
rule that's intended to apply to a specific file (e.g., the
`pyconfig.h` generated by `./configure`) but actually applies to all
similarly-named files in the tree (e.g., `PC/pyconfig.h`.)
Specifically, any rule with no non-trailing slashes is applied in an
"unrooted" way, to files anywhere in the tree. This means that if we
write the rules in the most obvious-looking way, then
* for specific files we want to ignore that happen to be in
subdirectories (like `Modules/config.c`), the rule will work
as intended, staying "rooted" to the top of the tree; but
* when a specific file we want to ignore happens to be at the root of
the repo (like `platform`), then the obvious rule (`platform`) will
apply much more broadly than intended: if someone tries to add a
file or directory named `platform` somewhere else in the tree, it
will unexpectedly get ignored.
That's surprising behavior that can make the .gitignore file's
behavior feel finicky and unpredictable.
To avoid it, we can simply always give a rule "rooted" behavior when
that's what's intended, by systematically using leading slashes.
Further, to help make the pattern obvious when looking at the file and
minimize any need for thinking about the syntax when adding new rules:
separate the rules into one group for each type, with brief comments
identifying them.
For most of these rules it's clear whether they're meant to be rooted
or unrooted, but in a handful of cases I've only guessed. In that
case the safer default (the choice that won't hide information) is the
narrower, rooted meaning, with a leading slash. If for some of these
the unrooted meaning is desired after all, it'll be easy to move them
to the unrooted section at the top.
(cherry picked from commit 455122a009)
Co-authored-by: Greg Price <gnprice@gmail.com>
Miss Islington (bot)
Stéphane Wirtel
Zachary Ware
Vinay Sajip
Brett Cannon
Andrew Svetlov