From: sashiko-bot@kernel.org
To: "Alison Schofield" <alison.schofield@intel.com>
Cc: linux-cxl@vger.kernel.org
Subject: Re: [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex
Date: Fri, 07 Aug 2026 00:03:44 +0000 [thread overview]
Message-ID: <20260807000345.86D851F000E9@smtp.kernel.org> (raw)
In-Reply-To: <d57d3ddc0d7d883bd61ad07c6d3969b622fd446f.1786058698.git.alison.schofield@intel.com>
Thank you for your contribution! Sashiko AI review found 1 potential issue(s) to consider:
- [Medium] The patch replaces `re.PatternError` with `re.error` rather than catching both, directly contradicting the commit message and exposing a misunderstanding of standard Python.
--
--- Patch [1]: [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex ---
commit ed601931671f151d8ef4f1bbd0e817520a34f3c5
Author: Alison Schofield <alison.schofield@intel.com>
docs: python: abi_regex: catch the right exception for a bad regex
This commit updates the exception handling in abi_regex.py to prevent the
script from aborting on invalid regular expressions. It aims to support
both older and newer Python releases by handling regex errors correctly.
> Older Python releases raise re.error, while newer releases expose
> re.PatternError. Catching only the newer name causes the scan to
> abort when an invalid expression is encountered.
>
> Catch both names so the scan continues and reports the remaining
> results.
[Severity: Medium]
Does the commit message accurately reflect the changes?
The text states it will "Catch both names", but the patch replaces
re.PatternError with re.error entirely. While standard Python uses re.error,
if newer releases actually exposed re.PatternError as stated in the commit
message, wouldn't replacing the handler cause newer Python releases to abort?
> diff --git a/tools/lib/python/abi/abi_regex.py b/tools/lib/python/abi/abi_regex.py
> --- a/tools/lib/python/abi/abi_regex.py
> +++ b/tools/lib/python/abi/abi_regex.py
> @@ -155,7 +155,7 @@ class AbiRegex(AbiParser):
> if self.search_string:
> if what.find(self.search_string) >= 0:
> print(f"What: {what}")
> - except re.PatternError:
> + except re.error:
[Severity: Medium]
Is it intentional to only catch re.error here in regex_append(), rather
than catching both as described in the commit message?
[ ... ]
> @@ -194,7 +194,7 @@ class AbiRegex(AbiParser):
>
> try:
> self.re_string = re.compile(self.search_string)
> - except re.PatternError as e:
> + except re.error as e:
[Severity: Medium]
Does this __init__() block also need to catch both exceptions, or is
replacing re.PatternError with re.error sufficient?
[ ... ]
> @@ -223,9 +223,9 @@ class AbiRegex(AbiParser):
> for r, s in self.re_whats:
> try:
> new = r.sub(s, new)
> - except re.PatternError as e:
> + except re.error as e:
> # Help debugging troubles with new regexes
> - raise re.PatternError(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
> + raise re.error(f"{e}\nwhile re.sub('{r.pattern}', {s}, str)") from e
[Severity: Medium]
Similar to the other locations, parse_abi() replaces the exception class
instead of catching both. Does this match the intended behavior?
--
Sashiko AI review · https://sashiko.dev/#/patchset/d57d3ddc0d7d883bd61ad07c6d3969b622fd446f.1786058698.git.alison.schofield@intel.com?part=1
next prev parent reply other threads:[~2026-08-07 0:03 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-08-06 23:49 [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex Alison Schofield
2026-08-06 23:49 ` [PATCH 2/2] docs: python: abi_regex: convert adjacent index placeholders Alison Schofield
2026-08-07 0:03 ` sashiko-bot [this message]
2026-08-07 0:37 ` [PATCH 1/2] docs: python: abi_regex: catch the right exception for a bad regex Alison Schofield
2026-08-07 14:42 ` Jonathan Corbet
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260807000345.86D851F000E9@smtp.kernel.org \
--to=sashiko-bot@kernel.org \
--cc=alison.schofield@intel.com \
--cc=linux-cxl@vger.kernel.org \
--cc=sashiko-reviews@lists.linux.dev \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.