[Python-ideas] ScopeGuardStatement/Defer Proposal

[Nathan Rice]

> Apparently I don't seem to like flow control constructs formed by
> "quoting" (in Lisp terms) a block of code and leaving its execution to
> some other party, with the exception of explicit function definitions.
> Maybe a computer-literate psychoanalyst can do something with this...
>
> To this day I am having trouble liking event-based architectures -- I
> do see a need for them, but I immediately want to hide their
> mechanisms and offer a *different* mechanism for most use cases. See
> e.g. the (non-thread-based) async functionality I added to the new App
> Engine datastore client, NDB:
> https://docs.google.com/document/pub?id=1LhgEnZXAI8xiEkFA4tta08Hyn5vo4T6HSGLFVrP0Jag
> . Deep down inside it has an event loop, but this is hidden by using
> Futures, which in turn are mostly wrapped in tasklets , i.e.
> yield-based coroutines. I expect that if I were to find a use for
> Twisted, I'd do most of my coding using its so-called inlineCallbacks
> mechanism (also yield-based coroutines). When I first saw Monocle,
> which offers a simplified coroutine-based API on top of (amongst
> others) Twisted, I thought it was a breath of fresh air (NDB is
> heavily influenced by it).

The main attraction of events for me is that they are a decent model
of computational flow that makes it easy to "reach into" other
people's code.  I won't argue against the statement that they can be
less clear or convenient to work with in some cases than other
mechanisms.  My personal preference would be to have the more powerful
mechanism as the underlying technology, and build simpler abstractions
on top of that (kind of like @property vs manually creating a
descriptor).

> I've probably (implicitly) trained most key Python developers and
> users to think similarly, and Python isn't likely to morph into Ruby
> any time soon. It's easy enough to write an event-based architecture
> in Python (see Twisted and Tornado); but an event loop is never going
> to be the standard way to solve all your programming problems in
> Python.

I agree that events can make code harder to follow in some cases.  I
feel the same way about message passing and channels versus method
invocation.  In both cases I think there is an argument to be made for
representing the simpler techniques as a special cases which are
emphasized for general use.  I also understand not wanting to be stuck
dealing with someone else's event or message passing fetish when it's
not necessary (and they often aren't), and that is certainly a fair
counterargument.

Thank you for clarifying your views somewhat, it was instructive.  I
enjoy writing python code in general, but I shouldn't let that lead me
astray when it isn't the right tool for the job.


Take care,

Nathan