add asyncio.__all__

[tungol]

This passes the stubtest checks for __all__ in the master branch of mypy.

Runtime just sums over the __all__ imported from each of the submodules. I tried that, but mypy didn't pick it up properly, so here's the explicit version, in all its messy glory.

[tungol]

Neither pyright nor pytype like this very much.

[tungol]

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.

[tungol]

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.

[tungol]

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.

[tungol]

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.

[github-actions]

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

[srittau]

I'm honestly not a fan of duplicating all items in each branch instead of using __all__ += ... inside the branches.

[tungol]

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.

[srittau]

I'm unsure what the better option is, but your logic makes sense.

[Akuli]

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.

[tungol]

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.