Re: [Python-ideas] revisit pep 377: good use case?
On Feb 29, 2012, at 8:01 PM, Nick Coghlan wrote:
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.
OK, then abstracting the concept of code running in a managed context wasn't the primary goal. That's too bad.
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.
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:
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
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:
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