[Python-ideas] Proposal: Allowing any variable to be used in a 'with... as...' expression

[Terry Reedy]

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 
> decorated.

Agreed

> 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.


 > (2)

 >     When a function returns something useful or None, I think an 
immediate
 >     test is generally good practice.  It will usually make the code 
clearer
 >     to readers.

> For the second one, I completely agree that an immediate test is good 
> practice,

Ok
  > /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) 
purpose.

-- 
Terry Jan Reedy