In text mode, the "size" parameter indicates the number of characters, not bytes.
(cherry picked from commit faff81c05f)
Co-authored-by: William Andrea <william.j.andrea@gmail.com>
Update the docs as patch can now return an AsyncMock if the patched
object is an async function.
(cherry picked from commit f5e7f39d29)
Co-authored-by: Mario Corchero <mcorcherojim@bloomberg.net>
This PR deprecate explicit loop parameters in all public asyncio APIs
This issues is split to be easier to review.
fourth step: queue.py
https://bugs.python.org/issue36373
(cherry picked from commit 9008be303a)
Co-authored-by: Emmanuel Arias <emmanuelarias30@gmail.com>
This PR deprecate explicit loop parameters in all public asyncio APIs
This issues is split to be easier to review.
Third step: locks.py
https://bugs.python.org/issue36373
(cherry picked from commit 537877d85d)
Co-authored-by: Emmanuel Arias <emmanuelarias30@gmail.com>
* bpo-351428: Updates documentation to reflect AsyncMock call_count after await.
* Adds skip and fixes warning.
* Removes extra >>>.
* Adds ... in front of await mock().
(cherry picked from commit b9f65f01fd)
Co-authored-by: Lisa Roach <lisaroach14@gmail.com>
The "A4" pdfs were previously the wrong size due to a change in the options in Sphinx 1.5.
See also sphinx-doc/sphinxGH-5235
(cherry picked from commit b5381f6697)
Authored-by: Jean-François B <jfbu@free.fr>
The link we have points to the version from Unicode 6.0.0, dated 2010.
There have been numerous updates to it since then:
https://www.unicode.org/reports/tr44/GH-Modifications
Change the link to one that points to the current version. Also, use HTTPS.
(cherry picked from commit 64c6ac74e2)
Co-authored-by: Greg Price <gnprice@gmail.com>
The purpose of the `unicodedata.is_normalized` function is to answer
the question `str == unicodedata.normalized(form, str)` more
efficiently than writing just that, by using the "quick check"
optimization described in the Unicode standard in UAX GH-15.
However, it turns out the code doesn't implement the full algorithm
from the standard, and as a result we often miss the optimization and
end up having to compute the whole normalized string after all.
Implement the standard's algorithm. This greatly speeds up
`unicodedata.is_normalized` in many cases where our partial variant
of quick-check had been returning MAYBE and the standard algorithm
returns NO.
At a quick test on my desktop, the existing code takes about 4.4 ms/MB
(so 4.4 ns per byte) when the partial quick-check returns MAYBE and it
has to do the slow normalize-and-compare:
$ build.base/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
-- 'unicodedata.is_normalized("NFD", s)'
50 loops, best of 5: 4.39 msec per loop
With this patch, it gets the answer instantly (58 ns) on the same 1 MB
string:
$ build.dev/python -m timeit -s 'import unicodedata; s = "\uf900"*500000' \
-- 'unicodedata.is_normalized("NFD", s)'
5000000 loops, best of 5: 58.2 nsec per loop
This restores a small optimization that the original version of this
code had for the `unicodedata.normalize` use case.
With this, that case is actually faster than in master!
$ build.base/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
-- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 561 usec per loop
$ build.dev/python -m timeit -s 'import unicodedata; s = "\u0338"*500000' \
-- 'unicodedata.normalize("NFD", s)'
500 loops, best of 5: 512 usec per loop
(cherry picked from commit 2f09413947)
Co-authored-by: Greg Price <gnprice@gmail.com>
* Fix suspicious.py to actually print the unused rules
* Fix the other `self.warn` calls
(cherry picked from commit e1786b5416)
Co-authored-by: Anthony Sottile <asottile@umich.edu>
Adds a link to `dateutil.parser.isoparse` in the documentation.
It would be nice to set up intersphinx for things like this, but I think we can leave that for a separate PR.
CC: @pitrou
[bpo-37979](https://bugs.python.org/issue37979)
https://bugs.python.org/issue37979
Automerge-Triggered-By: @pitrou
(cherry picked from commit 59725f3bad)
Co-authored-by: Paul Ganssle <paul@ganssle.io>
- drop TargetScopeError in favour of raising SyntaxError directly
as per the updated PEP 572
- comprehension iteration variables are explicitly local, but
named expression targets in comprehensions are nonlocal or
global. Raise SyntaxError as specified in PEP 572
- named expression targets in the outermost iterable of a
comprehension have an ambiguous target scope. Avoid resolving
that question now by raising SyntaxError. PEP 572
originally required this only for cases where the bound name
conflicts with the iteration variable in the comprehension,
but CPython can't easily restrict the exception to that case
(as it doesn't know the target variable names when visiting
the outermost iterator expression)
(cherry picked from commit 5dbe0f59b7)
"Arguments may be integers... " could be misunderstand as they also
could be strings.
New wording makes it clear that arguments have to be integers.
modified: Doc/library/datetime.rst
Automerge-Triggered-By: @pganssle
(cherry picked from commit c5218fce02)
Co-authored-by: Jürgen Gmach <juergen.gmach@googlemail.com>
Automerge-Triggered-By: @pganssle
