[Python-ideas] ScopeGuardStatement/Defer Proposal

[Matt Joiner]

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
passing.
On Feb 19, 2012 1:15 PM, "Nathan Rice" <nathan.alexander.rice at gmail.com>
wrote:

> > 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
> _______________________________________________
> Python-ideas mailing list
> Python-ideas at python.org
> http://mail.python.org/mailman/listinfo/python-ideas
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.python.org/pipermail/python-ideas/attachments/20120219/96569336/attachment.html>