On 30 Jan 2015 12:29, "Nikolaus Rath" Nikolaus@rath.org wrote:
Nick Coghlan ncoghlan-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org writes:
On 29 January 2015 at 15:49, Nikolaus Rath <
It's not a lot of code, but my feeling is that not anyone who might be interested in an "on_return" functionality would be able to come up
this right away.
What does it gain you other than saving a level of indentation over the form with an explicit context manager?
Nothing. But if that's not a good enough reason, why do we have contextlib.ContextDecorator?
I'm occasionally inclined to consider accepting that proposal a mistake on my part. It's certainly borderline.
That said, the main advantage that applies to ContextDecorator but not to this proposal is lightweight addition of "before & after" behaviour like serialisation, tracing or logging to a function - you just decorate it appropriately without touching any other part of the function. That's a useful thing to encourage, and it's handy that generator based context managers can be used that way by default.
This proposal is different:
* it's inherently coupled to the function body (you need to change the function signature, and allocate resources inside the function for later cleanup) * it's adding information about an implementation detail (how the function manages resource deallocation) to a header that's ideally focused on declaring the function's interface and externally visible behaviour
-- GPG encrypted emails preferred. Key id: 0xD113FCAC3C4E599F Fingerprint: ED31 791B 2C5C 1613 AF38 8B8A D113 FCAC 3C4E 599F
»Time flies like an arrow, fruit flies like a Banana.«
Python-ideas mailing list Pythonfirstname.lastname@example.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/