[Python-Dev] code blocks using 'for' loops and generators

[Samuele Pedroni]

Josiah Carlson wrote:
> Greg Ewing <greg.ewing at canterbury.ac.nz> wrote:
> 
>>Josiah Carlson wrote:
>>
>>
>>>Since PEP 310 was already mentioned, can we just say that the discussion
>>>can be boiled down to different ways of spelling __enter__/__exit__ from
>>>PEP 310?
>>
>>It's not quite the same thing. PEP 310 suggests a mechanism
>>with a fixed control flow -- do something on entry, do the
>>code block, do something on exit. A general block-passing
>>mechanism would give complete control to the function as
>>to when and how to call the block.
> 
> 
> I would like to ask a question.  Does Python want or need Ruby code
> blocks?  I ask because that is what is being offered to cure what ails
> us.  Don't get me wrong, I'm sure code blocks can solve quite a few
> problems (and is used as such in Ruby), but I'm not convinced that it is
> the solution for Python.
> 
> Any manual on Ruby will invariably discuss code blocks as one of the
> most powerful features Ruby has to offer.  Sounds great.  Sounds like a
> great big sledgehammer that can be used to do a bunch of things...so
> what is currently being proposed as a use for them, and what can't they
> do (that would be really nice)?
> 
> They are being offered, right now, as a setup and finalization mechanism. 
> Essentially a way of allowing people to wrap their own blocks of code in
> custom try/finally code, or whatever their minds can think up.  Ok,
> __enter__/__exit__ offers that.  What else?
> 
> If you were to pass your generator as a code block, then you could
> finalize a generator [1], and even raise exceptions in your code block,
> but it still wouldn't allow one to pass exceptions into a currently
> running generator (a long standing problem such that if we could, then
> we would get generator finalization for free [2]).
> 
> 
> What else?  Let's dig back into the python-dev archives...
> http://mail.python.org/pipermail/python-dev/2003-February/032739.html
> 
> Guido:
> 
>>- synchronized-like, where the block should connect to its environment
>>
>>- property-like, where the block should introduce a new scope, and the
>>  caller should be able to inspect or control that scope's namespace
> 
> 
> The synchronized-like thing is the custom try/finally, aka
> __enter__/__exit__ as specified in PEP 310.
> 
> The property-like thing was perhaps to be an easier way to generate
> properties, which fairly quickly fell to the wayside in discussion,
> seemingly because people didn't see a need to add thunks for this.
> 
> Later XML DOM parsing came into the discussion, and was quickly
> dismissed as being not possible due to the Python parser's limited
> lookahead.
> 
> Someone else mentioned that thunks could be used to generate a switch
> statement, but no elaboration was done, and no PEP was actually written
> (switch has also had its own PEP, and even talk of a peephole
> optimization for certain if/elif/else blocks to be made into dictionary
> lookups...)
> 
> 
> 
> So where has all this reading gotten me?  To the point that I believe
> previous discussion had concluded that Ruby-style code blocks have
> little use in Python.  *shrug*
> 

well, I think some people desire a more streamlined way of writing code
like:

def f(...)
...
def g(...)
...
x = h(...,f,g)

[property, setting up callbacks etc are cases of this]

were f,g etc definitions would appear inline and the whole has a
statement flavor; because this is Python a form that does not involve a
lot parantheses would be nice. Of course if the functions then are
allowed to change the surrounding bindings this could be used for
resource release issues etc.

Notice that decorators basically support a special case of this.

But yes, apart for the issue of rebinding (and if one wants non-local
returns), this is stricly about sugar.