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 <Nikolaus-BTH8mxji4b0@public.gmane.org> wrote:
> >> 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 with
> >> 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
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
> Code of Conduct: http://python.org/psf/codeofconduct/