On Mon, Nov 18, 2019, at 19:32, Soni L. wrote:
> let me ask again: can we make it so open() never fails, instead
> returning a file that can be either "open", "closed" or "errored"?
For one thing, it'd have to *truly never* fail. Not just on I/O errors but on
things like passing bad function arguments. That's hard to do with a function
written in C, and it would also mean when you eventually get the error the
traceback won't point at the line where you made a mistake.
And all "hybrid context manager" constructs would have to do this - not just
open but requests.get and sqlite3.connect and whatever else is out there.
I think the best we can do is make new context managers and encourage their
use, since the principle that context managers should not acquire resources
that will need to be released until __enter__ is called was broken at the very
beginning.
> operations on "errored" files would, well, raise.
>
> more specifically, __enter__ would raise.
>
> thus, `with (open("foo"), open("bar")) as (foo, bar):` would actually work.
_______________________________________________
Python-ideas mailing list -- python-ideas@python.org
To unsubscribe send an email to python-ideas-le...@python.org
https://mail.python.org/mailman3/lists/python-ideas.python.org/
Message archived at
https://mail.python.org/archives/list/python-ideas@python.org/message/EDN6V6Y2WLPABDDRIXWYGC4DLVC7H4TZ/
Code of Conduct: http://python.org/psf/codeofconduct/
