On Sat, Nov 16, 2019, at 16:13, Greg Ewing wrote:
> On 17/11/19 4:54 am, Ricky Teachey wrote:
>
> > I think it'd be at least as confusing as the current situation.
>
> It might be better to keep it as purely a context manager, and
> not load it down with any other baggage.
>
> I wouldn't try to make it remember the current directory. Like
> a generator expression, the expectation is that it would be
> used while it's still fresh.
>
> I seem to remember we had such a context manager for a brief
> time after the with-statement was invented, until someone had
> the bright idea to make open() do double duty.
>
> The main source of confusion I foresee if we re-introduce it,
> is that people are now used to doing 'with open()...', so we
> either make open() no longer a context manager and break
> existing code, or have two ways to do it, with the one that is
> currently the most widely used one having a subtle trap hidden
> in it.
I wonder if a general mechanism for turning badly behaved context manager
factories into nice ones would be a useful addition to contextlib. something
like this:
@contextmanager
def deferred_call(f, *args, **kwargs):
cm = f(*args, **kwargs)
res = cm.__enter__()
try:
yield res
finally:
cm.__exit__()
def deferred_caller(f, name=None):
return lambda *a, **k: deferred_call(f, *a, **k)
opener = deferred_caller(open)
_______________________________________________
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/M3YFDCLGSLCONYHSYDF47YP6XB7KUA5M/
Code of Conduct: http://python.org/psf/codeofconduct/
