On 19/11/2019 17:50, Soni L. wrote:
On 2019-11-19 3:37 p.m., Rhodri James wrote:
On 19/11/2019 17:12, Brian Skinn wrote:
@jayvdb on GitHub and I are working on a new version of one of my packages, stdio-mgr (https://github.com/bskinn/stdio-mgr), with a dramatically expanded API and capabilities.
Context managers feature heavily in the planned design; part of the design plan is to allow instantiation of a StdioManager object prior to entering a context, so that the user can tweak settings on the resulting object beforehand:
cm = StdioManager()
cm.setting = True cm.other_setting = False with cm: {do stuff with stdio managed}
If this paradigm holds, we will *specifically* be exploiting the distinction between __init__ and __enter__.
-42 to abolishing __enter__.
I concur. Logically the problem that people are complaining about is that we use open() as the context manager rather than a class that defers the actual file open to __enter__(). That's fixable by writing your own wrapper class, but having a builtin file context manager that deferred resource-consuming actions would be a Good Thing™
How about using Paths as file context managers? Just an idle thought.
I still feel like opening the file but delaying the exception would be more beneficial and have better semantics. It allows cd, mv, rm, etc to happen without any surprising semantics, and fits the model you want it to fit.
It really doesn't.
In my experience, lying to the user (or the compiler, or whatever) is very rarely a good idea. Either the file is open or it isn't, and finding out half a mile of text away from where the error actually occurred that it isn't doesn't give you much opportunity to fix things. As to the expected semantics of cd, mv, rm etc, I wouldn't expect those to work on an open file at all, and I wouldn't be sure what happened if they did.