On Nov 18, 2019, at 16:35, Soni L. fakedme+py@gmail.com wrote:
On 2019-11-18 5:22 p.m., Soni L. wrote:
On 2019-11-18 5:13 p.m., Andrew Barnert via Python-ideas wrote:
On Nov 18, 2019, at 10:51, Random832 random832@fastmail.com wrote:
On Mon, Nov 18, 2019, at 12:46, Paul Moore wrote: But open() isn't designed *just* to be used in a with statement. It can be used independently as well. What about
> f = open(filename)
header = f.readline() with f: # use f
> The open doesn't "create a future need to call __exit__". It *does*
require that the returned object gets closed at some stage, but you can do that manually (for example, if "header" in the above is "do not process", maybe you'd close and return early). > > sure, but "need to call close" is just a different spelling of "need to call __exit__".
Maybe I should ask the question the other way round. If we had
opened(), but not open(), how would you write open() using opened()? It is, after all, easy enough to write opened() in terms of open(). I would say open() is arguably a wart. Had context managers existed in the language all along, it should not be possible to do anything that creates an open-ended future requirement to do something (i.e. "require that the returned object gets closed at some stage") without either using a with statement or writing code to manually call __enter__ and __exit__. The likely most common case being a class that holds an open file, which should really have its own context manager that forwards to the file's. to that end, open() could look something like this: def open(*a,**k):
cm = opened(*a, **k) f = cm.__enter__() f.close = cm.__exit__ return f
I think in that hypothetical language you might want a generic “releaser” function, or method on all cms, or even special syntax, to turn any cm into something that you’ll take care of closing later manually (usually, but not necessarily, by using the closing cm on it in a different lexical context that you end up passing the released cm to).
(I think C++ smart pointers might be relevant here, or maybe something from Rust, although I haven’t thought it through in much detail.)
could we tweak open() so it doesn't raise immediately? this would make it play nicer with __enter__ but would probably break some things. this would make open() itself "never" fail.
let me ask again: can we make it so open() never fails, instead returning a file that can be either "open", "closed" or "errored"?
operations on "errored" files would, well, raise.
more specifically, __enter__ would raise.
thus, `with (open("foo"), open("bar")) as (foo, bar):` would actually work.
Sure, that could work. After all, when POSIX open returns -1, if you don’t check it explicitly and just start calling functions, they all fail with EBADFD. (Although, being C, you have to check _those_ failures explicitly—but that wouldn’t be an issue for Python.)
It seems like it would be just as much of a breaking change as everything else suggested here. Plenty of code expects open to fail immediately, and will do the wrong thing if it doesn’t, unless it’s all rewritten to use with immediately, and to use tuples as context managers rather than any other idiom when opening multiple files. Also, does every third-party (or maybe even stdlib?) file-like object that’s managing a resource have to change to not open the socket or whatever until you enter it?
But by the same token, I don’t think it breaks any _more_ code than the other ideas, and maybe it’s simpler than some of them?
But doesn’t that raise the same issue discussed in the other subthread of how you handle cases where you don’t want a context manager anywhere at all? Do you have to change them all to explicitly call __enter__, and then call __exit__ instead of close? Or do we add a really_open method paired with close for those cases? Or can we just ban all such cases and say that you’re always supposed to find a way to wrap them in a cm somehow?
One more thing: what happens when I, e.g., call open on an fd? Today we can expect that as soon as we do that, the file object owns the file handle. Either you’d change that so the file object doesn’t own the file handle until it’s entered, or you’d make open inconsistent about whether it owns a file object before enter, which could be confusing.