[Python-ideas] Defer Statement

[Joshua Morton]

Its also worth mentioning that the `defer` statement has come up in other
contexts, and is already often used as an identifier already (see
*https://mail.python.org/pipermail/python-ideas/2017-February/044682.html
<https://mail.python.org/pipermail/python-ideas/2017-February/044682.html>*),
so there are a lot of practical considerations for this to overcome even if
its deemed necessary (which I think Nick shows that it probably shouldn't
be).

--Josh


On Sat, Jun 3, 2017 at 8:24 AM Nick Coghlan <ncoghlan at gmail.com> wrote:

> On 3 June 2017 at 20:59, Daniel Bershatsky <bepshatsky at yandex.ru> wrote:
> > Dear Python Developers,
> >
> > We have a potential idea for enhancing Python. You will find a kind of
> draft
> > bellow.
>
> Thank you for taking the time to write this up!
>
> > Best regards,
> > Daniel Bershatsky
> >
> >
> > Abstract
> > ========
> >
> > This PEP proposes the introduction of new syntax to create community
> > standard,
> > readable and clear way to defered function execution in basic block on
> all
> > control flows.
> >
> > Proposal
> > ========
> >
> > There is not any mechanism to defer the execution of function in python.
>
> There is, thanks to context managers:
>
>     import contextlib
>     def foo(i):
>         print(i)
>
>     def bar():
>         with contextlib.ExitStack() as stack:
>             stack.callback(foo, 42)
>             print(3.14)
>
>     bar()
>
> Now, defer is certainly pithier, but thanks to contextlib2, the above
> code can be used all the way back to Python 2.6, rather than being
> limited to running on 3.7+. I was also motivated enough to *write*
> ExitStack() to solve this problem, but even I don't use it often
> enough to consider it worthy of being a builtin, let alone syntax.
>
> So while I'm definitely sympathetic to the use case (otherwise
> ExitStack wouldn't have a callback() method), "this would be useful"
> isn't a sufficient argument in this particular case - what's needed is
> a justification that this pattern of resource management is common
> enough to justify giving functions an optional implicit ExitStack
> instance and assigning a dedicated keyword for adding entries to it.
>
> Alternatively, the case could be made that there's a discoverability
> problem, where folks aren't necessarily being pointed towards
> ExitStack as a dynamic resource management tool when that's what they
> need, and to consider what could be done to help resolve that (with
> adding a new kind of statement being just one of the options
> evaluated).
>
> Cheers,
> Nick.
>
> P.S. Nikolas Rauth has a more in-depth write-up of the utility of
> ExitStack here:
> https://www.rath.org/on-the-beauty-of-pythons-exitstack.html
>
> --
> Nick Coghlan   |   ncoghlan at gmail.com   |   Brisbane, Australia
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> https://mail.python.org/mailman/listinfo/python-ideas
> Code of Conduct: http://python.org/psf/codeofconduct/
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20170603/f317ca1b/attachment.html>