[Python-ideas] ScopeGuardStatement/Defer Proposal
anacrolix at gmail.com
Sun Feb 19 08:36:48 CET 2012
Out of interest, do you see an alternative to events or message passing
when they _are_ required? I'm in Guido's apparently minority camp in that I
can't stand events. The only decent alternative I've seen is message
On Feb 19, 2012 1:15 PM, "Nathan Rice" <nathan.alexander.rice at gmail.com>
> > 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:
> > . 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
> > 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
> 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,
> Python-ideas mailing list
> Python-ideas at python.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Python-ideas