gh-95816: Fix TLS version range example in docs (GH-148574)
docs(ssl): Fix TLS version range example
(cherry picked from commit dbd8985e82)
Co-authored-by: Jan Brasna <1784648+janbrasna@users.noreply.github.com>
Link to existing rules in compound_stmts.rst (GH-149811)
In gh-138418, `!` was added to links to rules that don't exist in
the docs, in order to silence broken link warnings.
However, productionlist doesn't parse the `!`, which ends up in
the rendered documentation. (It's possible that gh-127835 broke
the `!` support.)
Replace the names with ones that appear in docs:
- `star_named_expression` in the grammar corresponds to
`flexible_expression` in the docs
- `star_named_expressions` in the grammar corresponds to
`flexible_expression_list` in the docs
- `named_expression` in the grammar corresponds to
`assignment_expression` in the docs
Having two sets of names isn't great of course. Consolidating them
is tracked in (subissues of) gh-127833.
(cherry picked from commit c37529293d)
Co-authored-by: Petr Viktorin <encukou@gmail.com>
gh-149663: fix typo in `unittest` docs (GH-149670)
`hastattr` -> `hasattr`
(cherry picked from commit 4956d2be9d)
Co-authored-by: Árni Már Jónsson <arnimarj@gmail.com>
docs: Clarify docs for error case of `PyDict_GetItemRef` (GH-149506)
(cherry picked from commit 3565d31690)
Co-authored-by: Nathan Goldbaum <nathan.goldbaum@gmail.com>
The power ABI specification requires that compilers maintain a back
chain by default, so unwinding already works without a dedicated
frame pointer. Don't use -fno-omit-frame-pointer on ppc64le.
-fno-omit-frame-pointer is not enough to make every target walkable by the
simple manual frame pointer unwinder.
The helper used by test_frame_pointer_unwind used to assume the frame pointer
named a two-word record where fp[0] was the previous frame pointer and fp[1]
was the return address. That is only the generic layout used by some targets.
This patch keeps that default, but moves the slots behind named offsets so
architecture-specific layouts can describe where the backchain and return
address really live.
On s390x, GCC and Clang do not emit a usable backchain unless -mbackchain is
enabled. Without it, the unwinder stops at the current C frame and the test
reports no Python frames. Once backchains are present, the helper must also
stop at the current thread's known C stack bounds; otherwise it can follow the
final backchain far enough to dereference an invalid frame and segfault.
For Linux s390x backchain frames, the documented z/Architecture stack-frame
layout saves r14, the return-address register, at byte offset 112 from the
frame pointer, so read the return address from that named slot instead of fp[1].
The 112-byte offset comes from Linux's s390 debugging documentation: its Stack
Frame Layout table shows z/Architecture backchain frames with the backchain at
offset 0 and saved r14 of the caller function at offset 112:
https://www.kernel.org/doc/html/v5.3/s390/debugging390.html#stack-frame-layout
This helper remains scoped to Linux s390x backchain frames. GNU SFrame's s390x
notes state that the s390x ELF ABI does not generally mandate where RA and FP
are saved, or whether they are saved at all:
https://sourceware.org/binutils/docs/sframe-spec.html#s390x
As Jens Remus noted, -fno-omit-frame-pointer is not needed when -mbackchain is
present.
On 32-bit ARM, GCC defaults to Thumb mode on common armhf toolchains. The Thumb
prologue keeps the saved frame pointer and link register at offsets that depend
on the generated frame, which breaks the fp[0]/fp[1] walk used by the helper.
Use -marm when it is supported for frame-pointer builds, and teach the helper
the GCC ARM-mode slots where the previous frame pointer is at fp[-1] and the
saved LR return address is at fp[0].
Co-authored-by: Petr Viktorin <encukou@gmail.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Claude Sonnet 4.6 <noreply@anthropic.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: Gregory P. Smith <greg@krypto.org>
When Levenshtein-based suggestions find no match for an AttributeError
on list, str, or dict, check a static table of common method names from
JavaScript, Java, C#, and Ruby.
For example, [].push() now suggests .append(), "".toUpperCase() suggests
.upper(), and {}.keySet() suggests .keys().
The list.add() case suggests using a set instead of suggesting .append(),
since .add() is a set method and the user may have passed a list where
a set was expected (per discussion with Serhiy Storchaka, Terry Reedy,
and Paul Moore).
Design: flat (type, attr) -> suggestion text table, no runtime
introspection. Only exact builtin types are matched to avoid false
positives on subclasses.
Discussion: https://discuss.python.org/t/106632
Co-authored-by: Matt Van Horn <455140+mvanhorn@users.noreply.github.com>
Co-authored-by: Victor Stinner <vstinner@python.org>
Co-authored-by: Claude Opus 4.6 (1M context) <noreply@anthropic.com>
* empty lines are always ignored instead of separating groups
* the "user-agent" line after a rule starts a new group
* groups matching the same user agent are now merged
* the rule with the longest match wins instead of the first matching rule
* in case of equal matches, the “Allow” rule wins over “Disallow”
* special characters “$” and “*” are now supported in rules
* prefer full match for user agent
Co-authored-by: dependabot[bot] <49699333+dependabot[bot]@users.noreply.github.com>
Co-authored-by: Benedikt Johannes <benedikt.johannes.hofer@gmail.com>
Co-authored-by: Hugo van Kemenade <1324225+hugovk@users.noreply.github.com>
Co-authored-by: blurb-it[bot] <43283697+blurb-it[bot]@users.noreply.github.com>
* Add Zd/Zf format support to array, memoryview and struct.
* ctypes: Replace F/D/G complex format with Zf/Zd/Zg.
* Modify array, ctypes and struct modules to support format strings
longer than 1 character (such as "Zd").
* Change array.typecodes type from str to tuple.
