Patch allows any iterable (such as set and frozenset) to be used for
__all__.

I also add some blank lines, making it more readable.

Does this break code that adds to __all__ using append() and extend()?  
See the os module for an example.

You don't check for NULL return from PyObject_GetIter(). It will
segfault for "__all__ = 1".

That demonstrates that test cases are missing from the patch. :)

Raymond: It shouldn't since __all__ is only inspected after the module
code has been executed.

The breakage isn't from the patch.  The problem would come from using a 
non-list iterable for __all__ which then breaks any other code that 
assumes __all__ is a list (the code is os is an example of how __all__ 
can get modified).  

AFAICT, this proposal doesn't add value, but it does complicate life 
for those wanting to access/modify __all__ but can no longer make 
assumptions about its type (perhaps it is a generator that can be read 
just once and any accessor would kill it in the process of examining 
it).  I don't see how this proposal adds value.  It's just a random 
change that doesn't make life any better for coders.

I agree. There seems to be no compelling use case.

tuples are already allowed for __all__, which breaks attempts to
monkey-patch it.

I did forget to check the return from PyObject_GetIter.