[Python-ideas] revisit pep 377: good use case?

[Craig Yoshioka]

On Feb 29, 2012, at 8:01 PM, Nick Coghlan wrote:

> On Thu, Mar 1, 2012 at 1:27 PM, Craig Yoshioka <craigyk at me.com> wrote:
>> But you're not going to win me over by saying that the #1 goal of 'with' is too best match the flow-control semantics of try|except|finally.
> 
> Um, you have that exactly backwards. *You* are the one agitating for
> change, therefore the onus is on *you* to demonstrate that the
> benefits exceed the costs.
> 

I am aware that I need to motivate against a lot of inertia... 'win me over' was just a statement that that particular line of argument was unlikely to make me concede since I had already thought it through, and still came to a different conclusion.  

> Read PEP 343 - the with statement is a tool created specifically to
> factor out try/except/finally statements where the body of the try
> block is the only part that changes. The fact that it has other use
> cases as well was an added bonus.
> 

OK, then abstracting the concept of code running in a managed context wasn't the primary goal.  That's too bad.

> *You* are the one suggesting that it be enhanced to do more, *despite*
> there being an existing PEP explicitly rejecting your proposed
> enhancements as introducing unnecessary complexity. I am merely
> telling you that the arguments you have presented so far are not
> persuasive, since they add nothing beyond those that I included when I
> wrote PEP 377.
> 

except PEP 377 failed partially because there wasn't a concrete real-world example of where it would be useful.  Thus, I thought presenting such an example might be enough to bring it up again.   

> Unless you have some compelling new information to present that can
> clearly be handled *only* by changing the way the with statement
> works, you're not going to win this one. Additional complexity is
> inherently bad, so, without presentation of clear gains in
> expressiveness and readability, the status quo will always win by
> default (See http://www.boredomandlaziness.org/2011/02/status-quo-wins-stalemate.html
> & http://www.boredomandlaziness.org/2011/02/justifying-python-language-changes.html)
> 

I gathered that that was your real argument, I just wanted it out.  So it's just a matter of wether my example is compelling *enough*.  I think my example is *compelling*, but can concede just one example still might not be good enough. 

As to the added 'complexity':
There's the code complexity.  I suspect that two or three lines of code would do it, but I'm still trying to interpret the Python compiler code, as this is the first time I've looked at it.
Then there's the conceptual complexity of the new behavior, but if all current code works the same, and there isn't a noticeable performance penalty, and people are extremely unlikely to run into context managers that use the new functionality anyways, I don't see that 'complexity' being an issue either.

I'm going to try and make the modifications and do some testing so I can make a stronger argument on the latter point.  I use a lot of third-party packages to test against, and have close to 1M lines of internal python code as well.