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

[Josiah Carlson]

Samuele Pedroni <pedronis at strakt.com> wrote:
> 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)?

[snip myself]

> > 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.

[snip myself]

Samuele:
> 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]


I think properties are the most used case where this kind of thing would
be nice.  Though the only thing that I've ever had a gripe with
properties is that I didn't like the trailing property() call - which is
why I wrote a property helper decorator (a use can be seen in [1]).  But
my needs are small, so maybe this kind of thing isn't sufficient for
those who write hundreds of properties.


> 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.

Resource release, right, already been discussed, and already known this
is a use case.  Now, people keep saying that using code blocks can make
things like properties easier to construct.  Ok, I'll bite, someone
write properties using code blocks.  I tried to, but I prefer original
properties to what I wrote.  Maybe someone who is a thunk advocate can
write something better.  Now's your chance, show the world how thunks
make properties prettier and easier to understand.  Feel free to use
whatever syntax is your favorite (if it may be ambiguous to third party,
document it). If someone can make a thunk that looks better than my
example [1] below, then I will agree that helping properties is a
legitimate use case (I have had serious doubts from the beginning), but
if not, then code blocks as a solution to the 'property problem' should
be taken off the table.


> 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.

But the sugar isn't all that sweet.  It solves the problem of resource
acquisition and release (also solved by PEP 310), and may help with
property-like things (helped by a decorator). Any other use cases for
one of the most powerful features of Ruby, in Python?


 - Josiah


[1] example use of my property helper decorator

class foo(object):
    
    prop = property_maker("put documentation here")
    
    @prop #getter
    def a(self):
        return 1
    
    @prop #setter
    def a(self, v):
        pass
    
    @prop #deleter
    def a(self):
        pass