On Mon, Nov 18, 2019, at 03:42, Paul Moore wrote:
> The context here has been lost - I've searched the thread and I can't
> find a proper explanation of how open() "misbehaves" in any way that
> seems to relate to this statement (I don't actually see any real
> explanation of any problem with open() to be honest). There's some
> stuff about what happens if open() itself fails, but I don't see how
> that results in a problem (as opposed to something like a subtle
> application error because the writer didn't realise this could
> happen).
>
> Can someone restate the problem please?
This particular chain of discussion is regarding a proposal to solve the
problem posed in the original topic by using a parenthesized tuple display,
i.e. code that looks like the following:
with (open(filename1), open(filename2)) as (file1, file2):
...
If there is no special handling for this syntax, this would be equivalent to:
files = (open(filename1), open(filename2))
with files as (file1, file2):
...
i.e. the `open` calls are all finished (and throw any exceptions) before the
tuple is constructed, and therefore its proposed __enter__ method cannot be
called. This means if open(filename2) fails, it is not protected by the with
block as it would be normally if the error occurred in the file object's
__enter__ method, and file1.__exit__() never gets called
The concept of a callable that returns a context manager (whether that is open,
requests.get, or any other context manager's constructor) and can throw an
exception is therefore a problem for the tuple.__enter__ proposal which was
being discussed in this subthread, and generally for any other construct like
it.
_______________________________________________
Python-ideas mailing list -- [email protected]
To unsubscribe send an email to [email protected]
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/[email protected]/message/BOR57AIUICRVBNRUQDHICUMS4SXPX3CA/
Code of Conduct: http://python.org/psf/codeofconduct/