[Python-Dev] Re: anonymous blocks

[Josiah Carlson]

"Fredrik Lundh" <fredrik at pythonware.com> wrote:
> 
> Josiah Carlson wrote:
> 
> > See the previous two discussions on thunks here on python-dev, and
> > notice how the only problem that seem bettered via blocks/thunks /in
> > Python/ are those which are of the form...
> > 
> > #setup
> > try:
> >     block
> > finally:
> >     #finalization
> > 
> > ... and depending on the syntax, properties.  I once asked "Any other
> > use cases for one of the most powerful features of Ruby, in Python?"  I
> > have yet to hear any sort of reasonable response.
> > 
> > Why am I getting no response to my question?  Either it is because I am
> > being ignored, or no one has taken the time to translate one of these
> > 'killer features' from Smalltalk or Ruby, or perhaps such translations
> > show that there is a better way in Python already.
> 
> for my purposes, I've found that the #1 callback killer in contemporary Python
> is for-in:s support for the iterator protocol:
...
> and get shorter code that runs faster.  (see cElementTree's iterparse for
> an excellent example.  for typical use cases, it's nearly three times faster
> than pyexpat, which is the fastest callback-based XML parser we have)

It seems as though you are saying that because callbacks are so slow,
that blocks are a non-starter for you because of how slow it would be to
call them.  I'm thinking that if people get correct code easier, that
speed will not be as much of a concern (that's why I use Python already). 
With that said, both blocks and iterators makes /writing/ such things
easier to understand, but neither really makes /reading/ much easier. 
Sure, it is far more terse, but that doesn't mean it is easier to read
and understand what is going on.

Which would people prefer?

@a(l):
    code

or

l.acquire()
try:
    code
finally:
    l.release()


> unfortunately,
> 
>     def do():
>         print "setup"
>         try:
>             yield None
>         finally:
>             print "tear down"
> 
> doesn't quite work (if it did, all you would need is syntactic sugar for "for
> dummy in").

The use 'for dummy in...' would be sufficient to notify everyone.  If
'dummy' is too long, there is always '_'.

This kind of thing solves the common case of setup/finalization, albeit
in a not-so-obvious-to-an-observer mechanism, which was recently loathed
by a nontrivial number of python-dev posters (me being one).  Looking at
it again, a month or so later, I don't know.  It does solve the problem,
but it introduces a semantic where iteration is used for something that
is not really iteration.

Regardless, I believe that solving generator finalization (calling all
enclosing finally blocks in the generator) is a worthwhile problem to
solve.  Whether that be by PEP 325, 288, 325+288, etc., that should be
discussed.  Whether people use it as a pseudo-block, or decide that
blocks are further worthwhile, I suppose we could wait and see.


> </F>
> 
> PS. a side effect of the for-in pattern is that I'm beginning to feel that Python
> might need a nice "switch" statement based on dictionary lookups, so I can
> replace multiple callbacks with a single loop body, without writing too many
> if/elif clauses.

If I remember correctly, Raymond was working on a peephole optimization
that automatically translated if/elif/else clauses to a dictionary
lookup when the objects were hashable and only the == operator was used. 
I've not heard anything about it in over a month, but then again, I've
not finished the implementation of an alternate import semantic either.

 - Josiah