"Moore, Paul" <Paul.Moore@atosorigin.com> writes:
> Consider
>
> try:
> f = open("blah.txt", "r")
> ...
> finally:
> f.close()
This should actually be
f = open("blah.txt", "r")
try:
...
finally:
f.close()
Otherwise if open raises an exception the finally clause will most
likely raise an exception as well.
> and with
>
> f = autoclose("blah.txt", "r")
> with f:
> ...
>
> The problem with the third case as compared to the second is that
> using autoclose() rather than open() has *no value* in the absence
> of the with statement. And contrariwise, if x is an object which
> hasn't been designed for use with the "with" construct, "with x"
> is meaningless.
Likewise, if x is not designed to be used with "for", "for i in x" is
meaningless (and throws an exception).
> So I guess what I'm saying is that "with ... autoclose" only
> make sense in combination.
I think "return autoclose(...)" will be used in function that create
objects for use in with clauses.
> Putting the two on different lines loses
> that connection. If you need to name the result of the autoclose()
> call, you either allow the with construct to include the assignment,
> or you lose that conceptual link.
IMO whether with should allow assignment is really completely independed
of "with". It's just the general design questions of whether to have
assignment expressions at all.
Bernhard
--
Intevation GmbH http://intevation.de/
Sketch http://sketch.sourceforge.net/
MapIt! http://www.mapit.de/
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4