Re: [Python-ideas] revisit pep 377: good use case?
On Feb 29, 2012, at 8:01 PM, Nick Coghlan wrote:
On Thu, Mar 1, 2012 at 1:27 PM, Craig Yoshioka <craigyk@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...)
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.
Hey, can we just let this PEP rest in peace? It was already rejected once. I don't see even a shimmer of support for reverting that decision. Please stop wasting everyone's time, Craig. Focus your energy somewhere productive. -- --Guido van Rossum (python.org/~guido)
On Thu, Mar 1, 2012 at 12:32 AM, Craig Yoshioka <craigyk@me.com> wrote: <craigyk@me.com> wrote:
except PEP 377 failed partially because there wasn't a concrete real-world example of where it would be useful.
But do you have one? I understand that you want the context to make the decision, instead of counting on a caller to do it properly. But why can't you do that with a decorator instead of a context? I think your examples are covered by http://wiki.python.org/moin/PythonDecoratorLibrary#Memoize Is it just that you want the stuff inside both your function and your context manager/decorator to have access to the same locals, and don't want to use a closure and/or pass around a dict? -jJ
On Thu, Mar 1, 2012 at 11:39 AM, Jim Jewett <jimjjewett@gmail.com> wrote:
Is it just that you want the stuff inside both your function and your context manager/decorator to have access to the same locals, and don't want to use a closure and/or pass around a dict?
It turned out that one important piece was that what a user considered a function was too large of a chunk for appropriate caching. That is an argument for a suite decorator, so as to avoid boilerplate code around each call. I'm not sure how *strong* the argument is though, because at least in his particular case, the cachable parts are sufficiently similar that they can be wrapped inside a calls to a "service provider", and the boilerplate can *probably* be moved there. -jJ
participants (3)
-
Craig Yoshioka -
Guido van Rossum -
Jim Jewett