docs: inconsistent open and io.open audit-event parameters

[bmwiedemann]

Bug report

Bug description:

While working on reproducible builds for openSUSE (sponsored by the NLnet NGI0 fund), I found that
our openSUSE:Factory/python312 doc varied in html/library/audit_events.html in a strange way:

 <td><p><a class="reference internal" href="../reference/datamodel.html#href_anchor">[1]</a></p></td>
 </tr>
 <tr class="row-odd"><td><p>open</p></td>
-<td><p><code class="docutils literal notranslate"><span class="pre">path</span></code>, <code class="docutils literal notranslate"><span class="pre">mode</span></code>, <code class="docutils literal notranslate"><span class="pre">flags</span></code></p></td>
+<td><p><code class="docutils literal notranslate"><span class="pre">file</span></code>, <code class="docutils literal notranslate"><span class="pre">mode</span></code>, <code class="docutils literal notranslate"><span class="pre">flags</span></code></p></td>
 <td><p><a class="reference internal" href="functions.html#href_anchor">[1]</a><a class="reference internal" href="io.html#href_anchor">[2]</a><a class="reference internal" href="os.html#href_anchor">[3]</a></p></td>
 </tr>

According to strace, this file is written by a call to ["sphinx-build", "-b", "html", "-d", "build/doctrees", "-j", "auto", ".", "build/html"]

All build output should be deterministic.

CPython versions tested on:

3.10, 3.11, 3.12

Operating systems tested on:

Linux

Linked PRs

• gh-121874: Define audit-event open parameters consistently #121883
• [3.12] gh-121874: Define audit-event open parameters consistently (GH-121883) #121955
• [3.13] gh-121874: Define audit-event open parameters consistently (GH-121883) #121956

[bmwiedemann]

My tools tell me, that the issue goes away, when both builds happen in 1-core-VMs, so it might be a race-condition.

[hugovk]

Sounds like something to report to Sphinx.

https://github.com/sphinx-doc/sphinx

[bmwiedemann]

It is probably sphinx-doc/sphinx#2946 = sphinx-doc/sphinx#6714 - open since many years.
For now, #121883 helps to avoid the issue.