[Python-ideas] ScopeGuardStatement/Defer Proposal

[Nathan Rice]

On Sat, Feb 18, 2012 at 10:30 AM, Nick Coghlan <ncoghlan at gmail.com> wrote:
> On Sat, Feb 18, 2012 at 8:16 AM, Nathan Rice
> <nathan.alexander.rice at gmail.com> wrote:
>> I just wanted to chime in on this, because I understand the use cases
>> and benefits of this but the code is very semantically opaque and
>> imperative.  I also feel like a lot of C programming concepts and
>> semantics have leaked into the design.  Additionally, I feel that
>> there are some benefits to taking a step back and looking at this
>> problem as part of a bigger picture.
>
> So... context managers are not a good fit for general event handling. Correct.
>
> Given that I agree with your basic point, I'm not sure what the rest
> of that had to do with anything, unless you heard the word "callback"
> and immediately assumed I was talking about general event handling
> rather than Go defer'ed style cleanup APIs (along with a replacement
> for the bug-prone, irredeemably flawed contextlib.nested API).

My point was more that I feel like you're hitting a point where the
context manager as a programming and semantic construct is starting to
stretch pretty thin.  My gut feeling is that it might be more
productive to let context managers alone (I think they're in an okay
place with multiple managers in a single with statement) and start to
examine the larger class of problems of which the deferred cleanup is
a member.  Events can unify a lot of concepts in python, while
providing a much more elegant handle into third party code than is
currently possible.  For example...

Decorators, descriptors and exceptions can all be unified neatly as
events, and events let you reach into 3rd party code in a robust
manner.  I can't tell you the number of times I have had to subclass
multiple things from a third party library to fix a small,
unnecessarily limiting design decision.  I've even run into this with
authors who make very elegant libraries like Armin; nobody can predict
all the use cases for their code.  The best thing we can do is make it
easy to work around such problems.

I like the with statement in general, but if python is ever going to
embrace events, the farther you travel along this path the more
painful switching over is going to be down the line.

> I'm not - what I'm planning would be a terrible API for general event
> handling. Fortunately, it's just a replacement for contextlib.nested()
> as a tool for programmatic management of context managers. If you want
> nice clean callbacks for general event handling, Python doesn't
> currently provide that. (We certainly don't have anything that gets
> remotely close to the elegance of Ruby's blocks for that style of
> programming: http://www.boredomandlaziness.org/2011/10/correcting-ignorance-learning-bit-about.html)

I like ruby's blocks a lot.  I don't think they don't drink enough of
the koolaid though.  Blocks can be a gateway to powerful macros (if
you have first class expressions) and a mechanism for very elegant
currying and partial function evaluation.

I think something that is missing for me is a clear picture of where
Python is going.  I imagine between you, Guido, Martin, Anton, Georg
and Raymond (apologies to any of the primary group I'm forgetting)
there is some degree of tacit understanding.  My perspective on python
was framed by Peter Norvig's description of it as aspiring to be a
humane reexamination of lisp, but lately I get the feeling the target
would better be described as a 21st century pascal.


Nathan