Josiah Carlson wrote: > > 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.
Not really -- I see the for-in loop body as the block. The increased speed is just a bonus. > 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). (Slightly OT, but speed is always a concern. I no longer buy the "it's python, it has to be slow" line of reasoning; when done correctly, Python code is often faster than anything else. cElementTree is one such example; people have reported that cElementTree plus Python code can be a lot faster than dedicated XPath/XSLT engines; the Python bytecode engine is extremely fast, also compared to domain-specific interpreters... And in this case, you get improved usability *and* improved speed at the same time. That's the way it should be.) > 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. Well, I was talking about reading here: with the for-in pattern, you loop over the "callback source", and the "callback" itself is inlined. You don't have to think in "here is the callback, here I configure the callback source" terms; just make a function call and loop over the result. > 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. Agreed. </F> _______________________________________________ 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
