[Python-ideas] Proposal: Allowing any variable to be used in a 'with... as...' expression
tjreedy at udel.edu
Sun May 19 14:32:16 EDT 2019
On 5/18/2019 10:44 PM, Yonatan Zunger wrote:
> Terry, let me make sure I'm understanding your responses.
> (1) Only certain things should be CM's, and those things should be
> explicitly denoted as such.
> Thinking about the first one, the purpose of the context manager
> protocol is to allow cleanups at scope exit, and I agree that only
> specified items should have these, and that this should be explicitly
> In this context, what I'm proposing is rather that the 'with'
> statement should be allowed to accept expressions which aren't context
> managers as well --
Disagree. This will masks bugs. The Python design philosophy is that
bugs should be visible and caught as soon as possible. It is
intentionally *not* stripped of all redundancy and compressed to the
minimum text posible.
There are languages which do not have or strongly avoid exceptions. One
way is to give objects artificial default values in expressions, such as
0 for + and - and 1 for + and /. Another way is to give expressions a
default backup value NUL or Bottom that propagates when used, much as
NaN does is floating point arithmetic. Python is not such a language.
> even though the 'with' statement provides no direct value in that case,
I see it as negative value.
> it simplifies larger code structure to do so,
It does not simplify the logic.
> because (as in the examples above) there are plenty of cases where the
> presence of a nontrivial context manager is conditional.
You have not even begun to show 'plenty'. You only showed a
hypothetical made-up function name. The real open() either returns a
file or raises an exception. I believe this is normal for functions
that return a context manager object.
> Essentially, a "noop with" improves code health,
> while not extending the context manager protocol itself.
Masking bugs decreases code health.
> When a function returns something useful or None, I think an
> test is generally good practice. It will usually make the code
> to readers.
> For the second one, I completely agree that an immediate test is good
> /if the return of None is actually an error. /
We may disagree on when returning None is an error for Python. Functions
that *always* return None because their only effect is a side-effect are
not an issue here. Functions that sometimes return a usable object and
sometimes raise or return None are always at least a bit of a nuisance.
There is no universal agreement on when to signal 'I cannot do that' 'in
band' (return None) or 'out of band' (raise exception). A general
discussion is out of scope here, but I suggested above than returning
None instead of a context manager object is a design error.
> The current rule uses the 'with' statement as an
> implicit error checker, but it goes off at inappropriate times because
> that was never its real purpose.
Why are you picking on 'with' statements? Every expression that is not
universally valid for all objects is an implicit error checker. In
Python, 'a + b' raises when appropriate, but that is not its main (real)
Terry Jan Reedy
More information about the Python-ideas