The enhancement is to add a __init__ method to both contextlib.ExitStack and contextlib.AsyncExitStack, so that you can pass (async)context managers directly in the costructor.

additionally, a new "context_managers" / "async_context_managers" field is added to retrieve the values passed


This will ease the usage with lists of context managers

instead of:

    with ExitStack() as stack:
        files = [stack.enter_context(open(fname)) for fname in filenames]

you can have

    with ExitStack(*(open(fname) for fname in filenames)) as stack:
        files = stack.context_managers

In my use case I have a fixed + variable number of (async)context managers, and I don't even need the "as" part

   ...
   in_send, in_receive = trio.open_memory_channel(0)
   out_sends, out_receives = [], []
   for _ in range(n): # n is dynamic
       out_send, out_receive = trio.open_memory_channel(0)
       out_sends.append(out_send)
       out_receives.append(out_receive)
   
   # syntax error
   async with in_send, in_receive, *out_sends, *out_receives:
       ...

   # with current AsyncExitStack
   async with AsyncExitStack() as stack:
       await stack.async_context_managers(in_send)
       await stack.async_context_managers(in_receive)
       for out_send in out_sends:
           await stack.async_context_managers(out_send)
       for out_receive in out_receives:
           await stack.async_context_managers(out_receives)
       ...

   # with the change
   async with AsyncExitStack(in_send, in_receive, *out_sends, *out_receives):
       ...

There used to be a contextlib.nested function which did this, and it was deprecated because there were problems with it. See here: https://docs.python.org/2/library/contextlib.html#contextlib.nested

Yes, this design has an incorrigible flaw.