Repository navigation
Emphasis compatibility regression in 3.11.1 when punctuation precedes the closing delimiter #1657
Description
Summary
After upgrading from Python-Markdown 3.11.0 to 3.11.1, emphasis is no longer rendered when its content ends with punctuation and the closing ** is immediately followed by ordinary text.
I traced the behavior change to commit 6f825aa753d672ec2d8ec5bc7b70d14b919d2fe1 in #1632. I understand from the discussion there that the punctuation-aware delimiter rules were deliberately added. This report asks whether the resulting loss of compatibility is intended, and whether there is an acceptable way to preserve the earlier behavior.
Minimal reproduction
import markdown
print(markdown.markdown("**단어(설명)**입니다."))Actual output in 3.11.1:
<p>**단어(설명)**입니다.</p>Expected output, matching 3.10.3 and 3.11.0:
<p><strong>단어(설명)</strong>입니다.</p>Version comparison
The following results were reproduced with Python 3.14.0 using the source from each release tag and master at 2258b48e551d0df7b149ea9c33969bea7c7a0a2b, without extensions.
| Input | 3.10.3 | 3.11.0 | 3.11.1 |
|---|---|---|---|
**단어(설명)**입니다. |
Strong | Strong | Literal |
**term(test)**suffix |
Strong | Strong | Literal |
**用語(test)**です |
Strong | Strong | Literal |
**术语(test)**是 |
Strong | Strong | Literal |
**term(test)** suffix |
Strong | Strong | Strong |
**term**suffix |
Strong | Strong | Strong |
Here, “Strong” means the intended content is wrapped in <strong>, and “Literal” means the ** markers remain in the output.
The issue is not specific to Korean or parentheses. For example:
import markdown
print(markdown.markdown("**term.**suffix"))
print(markdown.markdown("**term。**suffix"))
print(markdown.markdown("**term😀**suffix"))Actual output in 3.11.1:
<p>**term.**suffix</p>
<p>**term。**suffix</p>
<p>**term😀**suffix</p>Expected output, matching 3.11.0:
<p><strong>term.</strong>suffix</p>
<p><strong>term。</strong>suffix</p>
<p><strong>term😀</strong>suffix</p>Impact
In Korean, grammatical particles and endings are normally attached directly to the preceding expression. Emphasizing a term with a parenthetical explanation therefore naturally produces input such as **단어(설명)**입니다.. Requiring a space at that boundary changes how the sentence is written.
Existing documents that rendered emphasis before the upgrade now display literal Markdown markers. Similar constructions can occur in other languages, as the examples above show.
Questions
- Is the loss of emphasis in these previously supported constructions an intended compatibility change?
- Would you consider restoring the earlier behavior for these cases, or providing an opt-in compatibility setting or supported extension approach?
Activity
facelessuser commentedon Oct 14, 2026
For better or worse, this matches the CommonMark behavior as the new emphasis uses CommonMark punctuation rules. Escaping the parentheses allows it to work:
If this is a problem, we could make the punctuation rules optional.
facelessuser commentedon Oct 14, 2026
For more clarity, this is supposed to allow for more sane logic around punctuation.
*(**test**) more text*So it would yield
(test) more text
instead of
( test ) more text
facelessuser commentedon Oct 14, 2026
To be fair, in most English environments, I suspect these kinds of cases would rarely come up, but maybe not so much in some non-English languages.
waylan commentedon Oct 14, 2026
I didn't really think about non-English contexts being different for this based on the fact that this is the behavior of Commonmark. Now that I know that, I'm wondering if perhaps we should revert that change in behavior and allow an extension to offer the Commonmark behavior.
facelessuser commentedon Oct 14, 2026
@waylan I'm okay with that. It was either to make the punctuation rules optional (even off by default) or pull them out entirely. When I proposed them, I was prepared to leave them out if asked.
waylan commentedon Oct 14, 2026
Let's do that then. Your extension can offer the new behavior for those who want/need it and the default behavior can remain unchanged from 3.11 for punctuation.
Sorry I didn't think that through completely before.
facelessuser commentedon Oct 14, 2026
I didn't think it through either, as I was coming from an English usage perspective.
I'll create a PR that removes the punctuation rules, and BetterEm can be used to get full CommonMark behavior, though I'll probably allow punctuation in BetterEm to be toggled off if anyone wants to.
Python Markdown, in that respect, can retain the old-school rules but still have the better handling for nesting.
facelessuser commentedon Oct 14, 2026
I've created the PR.
qu3vipon commentedon Oct 15, 2026
Thank you for the quick response and for taking this into consideration.