Support configparser.UNNAMED_SECTION (#13542)

[mtnpke]

UNNAMED_SECTION was added in Python 3.13 and can be used in place of any section name. It is not actually a string though, so it needs a separate type.

[srittau]

Thanks. I don't think, the DEFAULT section can be used everywhere. See below.

[mtnpke]

@srittau Not sure what you're talking about; this PR is about unnamed section, which is unrelated to the default section and can absolutely be used for sections() and options().

[mtnpke]

Python 3.13.1 (tags/v3.13.1:0671451, Dec  3 2024, 19:06:28) [MSC v.1942 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> import configparser
>>> cp = configparser.ConfigParser(allow_unnamed_section=True)
>>> cp.read_string("a=1\n[sec]b=2")
>>> cp.sections()
[<UNNAMED_SECTION>, 'sec']
>>> type(cp.sections()[0])
<class 'configparser._UnnamedSection'>
>>> type(cp.sections()[1])
<class 'str'>
>>> cp.has_section(configparser.UNNAMED_SECTION)
True
>>> cp.options(configparser.UNNAMED_SECTION)
['a']
>>>

[srittau]

I was mixing up unnamed and default sections it seems. That said, can you try one thing, please. See below. This will hopefully fix the new mypy primer hits.

[srittau]

Suggested change

	def sections(self) -> list[_SectionName]: ...
	# This list can only include an unnamed section if the parser was initialized with
	# allow_unnamed_section=True. Any prevents users from having to use explicit
	# type checks if allow_unnamed_section is False (the default).
	def sections(self) -> list[str | _UNNAMED_SECTION | Any]: ...

[mtnpke]

this will not work because _UNNAMED_SECTION does not exist for python < 3.13

[mtnpke]

I'm not a big fan of this in general because it limits the usefulness of type checking, but if it's a requirement that mypy_primer does not fail we can try it

[srittau]

It's probably better to have separate branches for Python >= 3.13 and Python < 3.12 here anyway, so that < 3.12 can get tighter types here.

In typeshed, usability is a major concern. As the primer output shows, code that is currently working correctly would need additional churn with this change. This is something we want to avoid.

[mtnpke]

I assume you mean "< 3.13". It already has tighter types because of the type aliases. <3.13 will get list[str], as before.

As the types were objectively wrong before (as far as >= 3.13 is concerned!), it will be difficult to get it working without changes to existing code. What do you suggest?

I was mixing up unnamed and default sections.

[mtnpke]

@srittau It does not help, unfortunately.

[srittau]

Hmm, yes I wasn't sure if the "Any trick" worked in this situation. Unfortunately, the best we can do here is use list[Any] as return type (for >= 3.13). This is another one of the situation where AnyOf (python/typing#566) would help.

[srittau]

Thanks!

[github-actions]

According to mypy_primer, this change has no effect on the checked open source code. 🤖🎉