Hello, The other day, I was looking for an "atexit" equivalent at the function level. I was hoping to replace code like this: def my_function(bla, fasel): with ExitStack() as cm: ... cm.push(...) ... with something like: @handle_on_return def my_function(bla, fasel, on_return): ... on_return.push(...) ... It seems that contextlib *almost* offers a way to do this with ExitStack and ContextDecorator - but as far as I can tell the final piece is missing, because ContextDecorator does not offer a way to pass the context manager to the decorated function. However, the following decorator does the job: def handle_on_return(fn): @functools.wraps(fn) def wrapper(*a, **kw): with contextlib.ExitStack() as on_return: kw['on_return'] = on_return return fn(*a, **kw) return wrapper 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. Would it make sense to add something along these lines to contextlib? Maybe instead of a new decorator, ContextDecorator could also take an additional keyword argument that tells it to pass the context manager to the decorated function? Best, -Nikolaus -- 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.«
On 29 January 2015 at 15:49, Nikolaus Rath <Nikolaus@rath.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? The version with the magic hidden wrapper will also be slower than the explicit form, and will break parameter prompting in most IDEs. Cheers, Nick. -- Nick Coghlan | ncoghlan@gmail.com | Brisbane, Australia
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 contextlib.ContextDecorator? Best, -Nikolaus -- 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.«
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 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 Cheers, Nick.
Best, -Nikolaus
-- 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 Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
participants (2)
-
Nick Coghlan -
Nikolaus Rath