"Fredrik Lundh" <[EMAIL PROTECTED]> 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
_______________________________________________
Python-Dev mailing list
Python-Dev@python.org
http://mail.python.org/mailman/listinfo/python-dev
Unsubscribe:
http://mail.python.org/mailman/options/python-dev/archive%40mail-archive.com
