test_subparser_inherits_reparse_deferral fails when compiled against expat < 2.6.0

[hroncok]

Bug report

Bug description:

test_subparser_inherits_reparse_deferral, added in 7d76013, fails when CPython is compiled against expat < 2.6.0:

test_subparser_inherits_reparse_deferral (test.test_pyexpat.ParentParserLifetimeTest.test_subparser_inherits_reparse_deferral) ... FAIL
======================================================================
FAIL: test_subparser_inherits_reparse_deferral (test.test_pyexpat.ParentParserLifetimeTest.test_subparser_inherits_reparse_deferral)
----------------------------------------------------------------------
Traceback (most recent call last):
  File "/builddir/build/BUILD/Python-3.13.15/Lib/test/test_pyexpat.py", line 960, in test_subparser_inherits_reparse_deferral
    self.assertEqual(subparser.GetReparseDeferralEnabled(), enabled)
    ~~~~~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: False != True
----------------------------------------------------------------------

With XML_COMBINED_VERSION < 20600, SetReparseDeferralEnabled is a complete no-op -- both the expat call and the cache update are inside #if XML_COMBINED_VERSION >= 20600. The cache stays at its initial value of false, which the subparser copies and GetReparseDeferralEnabled returns. The test's enabled=True iteration then asserts False == True.

This is consistent with the documented behavior: GetReparseDeferralEnabled says "always returns false with Expat <2.6.0".

I belive a simple fix for the test failure would be a version-based skip:

@unittest.skipIf(expat.version_info < (2, 6, 0),
                 "requires Expat >= 2.6.0")
def test_subparser_inherits_reparse_deferral(self):
    ...

However, the runtime expat version can differ from the compile-time one. Since the behavior is gated by the compile-time XML_COMBINED_VERSION check, it's more robust to test the compile-time default directly (similar to GH-144739 / 45e9343):

@unittest.skipIf(not expat.ParserCreate().GetReparseDeferralEnabled(),
                 "requires Python compiled with Expat >= 2.6.0")
def test_subparser_inherits_reparse_deferral(self):
    ...

A freshly created parser's GetReparseDeferralEnabled() reflects which #if branch was compiled -- True with expat >= 2.6.0, False otherwise.

Would that be an acceptable change?

Disclosure: I used LLM (Claude Opus 4.6) to analyze the cause of the test failure we see in EPEL 9.

CPython versions tested on:

3.13, CPython main branch

This has been reproduced on 3.13.15 with RHEL 9 expat 2.5.0 (which actually backported XML_SetReparseDeferralEnabled without XML_GetReparseDeferralEnabled but the buildttime version #if makes that irrelevant anyway). Based on the presence of the same code in the main branch, I assume this is also the same for newer Python versions.

Operating systems tested on:

Linux

Linked PRs

• gh-155485: Skip test_subparser_inherits_reparse_deferral with Expat < 2.6.0 #155554
• [3.14] gh-155485: Skip test_pyexpat.test_subparser_inherits_reparse_deferral when Expat < 2.6.0 (GH-155554) #155572
• [3.13] gh-155485: Skip test_pyexpat.test_subparser_inherits_reparse_deferral when Expat < 2.6.0 (GH-155554) #155573
• [3.15] gh-155485: Skip test_pyexpat.test_subparser_inherits_reparse_deferral when Expat < 2.6.0 (GH-155554) #155574

[AyushkhatiDev]

Hi @hroncok , I’d be happy to work on this.

The compile-time behavior check via ParserCreate().GetReparseDeferralEnabled() makes sense to me, especially given that the runtime Expat version can differ from the version CPython was compiled against.

I’ll first verify the existing test/code patterns and the precedent you mentioned, then I can submit a focused PR with the minimal test skip if everything checks out.

[StanFromIreland]

Checking for the method is fine. @AyushkhatiDev please first check if the person opening the issue (@hroncok) would like to write the patch themselves.

[hroncok]

@AyushkhatiDev Thanks for trying to help. However, conisdering I already proposed the chnage here, I was planing to send a PR myself if there is no pushback.

[AyushkhatiDev]

Thanks for clarifying! No problem — I’ll leave this one to @hroncok