[Python-ideas] for line in input with open(path) as input...
Nick Coghlan
ncoghlan at gmail.com
Sun Feb 3 05:26:29 CET 2013
On Sun, Feb 3, 2013 at 1:47 AM, Yuval Greenfield <ubershmekel at gmail.com> wrote:
> I really like Golang's solution (defer) which Nick sort of emulates with
> ExitStack.
>
> http://docs.python.org/3/library/contextlib.html#contextlib.ExitStack
>
> If ExitStack ever became a language feature
Why would it ever become a language feature? It works just fine as a
context manager, and the need for it isn't frequent enough to justify
special syntax.
> we could write stuff like:
>
>
> def f():
> fhand = local open(path)
> process(fhand)
> ghand = local open(path2)
> process(ghand)
Why would you leave fhand open longer than necessary? The above would
be better written as:
def f():
with open(path) as fhand:
process(fhand)
with open(path2) as ghand:
process(ghand)
If you need both files open at the same time, you can use a nested
context manager:
def f():
with open(path) as fhand:
with open(path2) as ghand:
process(fhand, ghand)
Or the nesting behaviour built into with statements themselves:
def f():
with open(path) as fhand, open(path2) as ghand:
process(fhand, ghand)
It's only when the number of paths you need to open is dynamic that
ExitStack comes into play (this is actually very close to the example
in ExitStack's docstring, as handling a variable number of
simultaneously open files was the use case that highlighted the fatal
flaw in the way the old contextlib.nested design handled context
managers that acquired the resource in __init__ rather than
__enter__):
def f(*paths):
with contextlib.ExitStack() as stack:
files = [stack.enter_context(open(path)) for path in paths]
process(files)
Function and class definitions control name scope (amongst other
things), with statements control deterministic cleanup, loops control
iteration. That's what I mean by "separation of concerns" in relation
to these aspects of the language design and it's a *good* thing (and
one of the key reasons with statements behave like PEP 343, rather
than being closer to Guido's original looping idea that is described
in PEP 340).
Cheers,
Nick.
--
Nick Coghlan | ncoghlan at gmail.com | Brisbane, Australia
More information about the Python-ideas
mailing list