3.11.0b3: document conflicting subparsers

[supakeen]

Bug report

In ad5e8520f3e the behaviour of add_parser was changed to raise an exception when a parser with the same name is added. This leads to failures in test cases (such as: Azure/azure-cli#23015).

It seems to me that this change should/could be documented in the "What's New" section for Python 3.11.

Your environment

pyenv + Python 3.11b3.

Output

user@desktopa ~ € python3.10 -V
Python 3.10.5
user@desktopa ~ € python3.10 test.py
user@desktopa ~ € python3.11 -V
Python 3.11.0b3+
user@desktopa ~ € python3.11 test.py 
Traceback (most recent call last):
  File "/home/supakeen/test.py", line 5, in <module>
    p.add_parser("foo")
    ^^^^^^^^^^^^^^^^^^^
  File "/home/supakeen/.pyenv/versions/3.11-dev/lib/python3.11/argparse.py", line 1185, in add_parser
    raise ArgumentError(self, _('conflicting subparser: %s') % name)
    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
argparse.ArgumentError: argument {foo}: conflicting subparser: foo
user@desktopa ~ € cat test.py
import argparse

p = argparse.ArgumentParser().add_subparsers()
p.add_parser("foo")
p.add_parser("foo")

[saito828koki]

That change is documented here, and you can see it in the changelog of What's new in Python.

cpython/Misc/NEWS.d/3.11.0b1.rst

Lines 1660 to 1662 in 3440d19

	Raise an ArgumentError when the same subparser name is added twice to an
	`argparse.ArgumentParser`. This is consistent with the (default) behavior
	when the same option string is added twice to an ArgumentParser.

[supakeen]

@saito828koki Thank you, I must've missed that.