Allow walrus operators in allow-list of statically parseable __all__ extensions

[nstarman]

X-ref astral-sh/ruff#7672 where this was first noticed.

There are a set of ways to extend __all__ that can be passed statically and should be supported by static type checkers. However, I think that this list is incomplete, particularly that it is lacking support for expressions containing walrus operators.

For example

__all__ = ["a", "b"]
__all__ += (variable := ["c", "d"])

is parseable statically to understand that the assignment to variable does not change what is assigned to __all__.

I have added this to the list of supported idioms.

[cpython-cla-bot]

All commit authors signed the Contributor License Agreement.

[erictraut]

This is an uncommon pattern (I've never seen it before), so I don't think this should be added to the list of supported idioms for static analysis tools. Every new pattern requires custom logic in all static analysis tools, so we should be very careful about adding new forms.

There's a straightforward workaround in this case, and I recommend that the maintainers of this library stick to the standard agreed-upon patterns for __all__ manipulation.

[AlexWaygood]

__all__ is a variable that must be heavily special-cased by type checkers in order for them to have an accurate understanding of Python's import semantics. Each item on this list requires separate special casing from type checkers in order for it to be supported.

This list is the closest thing we have to a spec for this — by adding things to this list, we are essentially stating that we now expect more from type checkers if they want to be considered in compliance with the spec. Is there a real-world use case here, that can't be easily adapted to use one of the supported idioms, to motivate asking type checkers to take on that additional maintenence burden? I agree with @erictraut that this seems a pretty uncommon pattern.

I'd want to see support (or at least lack of opposition) from all major type checkers before adding to this list. The primary maintainer of one major type checker already came out against this before I finished writing this message :-)