[Python-ideas] ScopeGuardStatement/Defer Proposal

[Guido van Rossum]

On Sat, Feb 18, 2012 at 2:33 PM, Nathan Rice
<nathan.alexander.rice at gmail.com> wrote:
> 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.

Was that meant as an insult? Because it sounds to me like one.

-- 
--Guido van Rossum (python.org/~guido)