VOC has been archived by the BeeWare project, and they are instead
embedding CPython, rather than transpiling to Java bytecode.
(cherry picked from commit bb900712a5)
Co-authored-by: Carl Bordum Hansen <carl@bordum.dk>
* bpo-42272: improve message/module warning filter docs
"The Warnings Filter" section of the warnings module documentation
describes the message and module filters as "a string containing a
regular expression". While that is true when they are arguments to the
filterwarnings function, it is not true when they appear in -W or
$PYTHONWARNINGS where they are matched literally (after stripping any
starting/ending whitespace). Update the documentation to note when they
are matched literally. Also clarify that module matches the
"fully-qualified module name", rather than "module name" which is
ambiguous.
skip news (since this is a doc fix)
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* bpo-42272: remove bad submodule warning filter doc
The `error:::mymodule[.*]` example in the "Describing Warning Filters"
section of the warnings module documentation does not behave as the
comment describes. Since the module portion of the filter string is
interpreted literally, it would match a module with a fully-qualified
name that is literally `mymodule[.*]`.
Unfortunately, there is not a way to match '"module" and any subpackages
of "mymodule"' as documented, since the module part of a filter string
is matched literally. Instead, update the filter and comment to match
only "mymodule".
skip news (since this is a doc fix)
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
* bpo-42272: add warning filter doc changes to NEWS
Signed-off-by: Kevin Locke <kevin@kevinlocke.name>
(cherry picked from commit 8136606769)
Co-authored-by: Kevin Locke <kevin@kevinlocke.name>
This is a rework of GH-5774 on current main. I was a bit more
conservative in making changes than the original PR.
See @csabella's comments on issue GH-77024 and the discussion
on GH-5774 for explanations of several of the changes.
Co-authored-by: Cheryl Sabella <cheryl.sabella@gmail.com>
Co-authored-by: Alex Waygood <Alex.Waygood@Gmail.com>
(cherry picked from commit 8995177030)
Co-authored-by: Jelle Zijlstra <jelle.zijlstra@gmail.com>
Fix __ltrace__ debug feature if the stdout encoding is not UTF-8.
If the stdout encoding is not UTF-8, the first call to
lltrace_resume_frame() indirectly sets lltrace to 0 when calling
unicode_check_encoding_errors() which calls
encodings.search_function().
Add test_lltrace.test_lltrace() test.
test.pythoninfo no longer fails if "import socket" fails: the socket
module is now optional.
(cherry picked from commit 4a31ed8a32)
Co-authored-by: Victor Stinner <vstinner@python.org>
The code was moved out of test.support in
311110abcd (GH-20812), thus making
ResourceDenied undefined.
(cherry picked from commit 37c9a351b1)
Co-authored-by: Florian Bruhin <me@the-compiler.org>
Also while there, clarify a few things about why we reduce the hash to 32 bits.
Co-authored-by: Eli Libman <eli@hyro.ai>
Co-authored-by: Yury Selivanov <yury@edgedb.com>
Co-authored-by: Łukasz Langa <lukasz@langa.pl>
(cherry picked from commit c1f5c903a7)
This fixes an issue on tutorial/classes.rst section 9.4 where the example "class Warehouse"
was truncated when pressing the >>> button to hide the prompts and output.
(cherry picked from commit 88f0d0c1e8)
Co-authored-by: Nicolas Haller <nicolas@haller.im>
If Condition.notify() was interrupted just after it released the waiter lock,
but before removing it from the queue, the following calls of notify() failed
with RuntimeError: cannot release un-acquired lock.
(cherry picked from commit 70af994fee)
Co-authored-by: Serhiy Storchaka <storchaka@gmail.com>
The `utc_to_seconds` call can fail, here's a minimal reproducer on
Linux:
TZ=UTC python -c "from datetime import *; datetime.fromtimestamp(253402300799 + 1)"
The old behavior still raised an error in a similar way, but only
because subsequent calculations happened to fail as well. Better to fail
fast.
This also refactors the tests to split out the `fromtimestamp` and
`utcfromtimestamp` tests, and to get us closer to the actual desired
limits of the functions. As part of this, we also changed the way we
detect platforms where the same limits don't necessarily apply (e.g.
Windows).
As part of refactoring the tests to hit this condition explicitly (even
though the user-facing behvior doesn't change in any way we plan to
guarantee), I noticed that there was a difference in the places that
`datetime.utcfromtimestamp` fails in the C and pure Python versions, which
was fixed by skipping the "probe for fold" logic for UTC specifically —
since UTC doesn't have any folds or gaps, we were never going to find a
fold value anyway. This should prevent some failures in the pure python
`utcfromtimestamp` method on timestamps close to 0001-01-01.
There are two separate news entries for this because one is a
potentially user-facing change, the other is an internal code
correctness change that, if anything, changes some error messages. The
two happen to be coupled because of the test refactoring, but they are
probably best thought of as independent changes.
Fixes GH-91581
(cherry picked from commit 83c0247d47)
Co-authored-by: Paul Ganssle <1377457+pganssle@users.noreply.github.com>
It fixes 252 errors from a Sphinx nitpicky run (sphinx-build -n). But
there's 8182 errors left.
Co-authored-by: Ezio Melotti <ezio.melotti@gmail.com>
(cherry picked from commit 664aa94b57)
Co-authored-by: Julien Palard <julien@palard.fr>
