Neither pyright nor pytype like this very much.

It seems that pyright and pytype gained support for += on __all__ in #7865 if __all__ is a list, but not if it's a tuple. I could work around that here, but that seems like it'd be even worse than this version.

The pytype error is slightly different. mypy complained about changing the length of the tuple type, which I worked around with the annotation of it as tuple[str, ...]. That's making pytype complain that __all__ isn't a literal. I guess with a list __all__, using += preserves the Literal status?

I'm not certain what, if any, annotation would satisfy both needs.

Well, as Eric pointed out, this isn't in the typing spec.

Technically this doesn't go beyond the typing spec:

__all__ = ('a', 'b')
__all__ += submodule.__all__

where submodule is also a tuple __all__. But mypy doesn't support this and I suspect neither does pyright.

I updated the MR to just be one giant platform x version matrix. It's not pretty and updating it won't be very ergonomic, but I don't see what other choice we have.

Me neither, but __all__ in these files is a tuple at runtime. Mypy and pyright don't support using __all__ += ... with tuple __all__.

If we want to diverge from runtime and use a list for __all__, then this could be a lot nicer. I didn't do that because all the submodules here match runtime at the cost of this sort of thing already.

Can't we just use lists if they work better with type checkers? In basically every use case of __all__, it doesn't matter whether it's a list or a tuple.

If we do that, we should probably get stubtest updated to ignore the type discrepancy on __all__. If we have to add asyncio.*.__all__ to the allowlist for the tuple/list mismatch, it will also hide the more important names exported from the stub do not correspond to the names exported at runtime error.

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

This is ugly, but other solutions also have problems, and if we miss a change in the future, stubtest will tell us, so the maintenance risk isn't that high.