j: Next unread message
k: Previous unread message
j a: Jump to all threads
j l: Jump to MailingList overview
On Sat, Apr 11, 2009 at 5:32 AM, Nick Coghlan firstname.lastname@example.org wrote:
Jacob Holm wrote:
I am not really sure about this. It looks very much like an implementation detail to me. On the other hand, the ability to replace the methods mid-flight might give us a way to implement the call-wrappers with minimal overhead. Since the current patches don't actually do any caching, this is something I should actually be able to try.
The part that makes me nervous is the fact that the PEP as it stands gives the green light to an implementation having different bound method caching behaviour between for loops and the yield-from expression.
That goes against Guido's request that the degenerate case of yield-from have the same semantics as:
for x in subiter: yield x
Since the language reference is actually silent on the topic of caching the bound method when iterating over an object, I would phrase it along the following lines:
- if for loops in a Python implementation cache next(), then yield-from in that implementation should also cache next() - if yield-from caches next(), it should also cache sent() and throw() - Since CPython for loops don't cache the bound method for next(), it won't cache the methods used by yield-from either
In ceval.c, the FOR_ITER opcode expects the iterator on top of the stack and calls (v->ob_type->tp_iternext)(v).
You tell me whether that is caching or not. :-)
Who knows, maybe Guido will actually clarify the matter for us when he gets back from his vacation :)
Or sooner. :-)
P.S. Speaking of vacations, I'll also be offline for the next week or so (starting tomorrow), and then my internet access for Python activities will be sketchy for another couple of weeks as I move house. So I won't be able to contribute much more to this discussion.
Good, let this be a general trend. :-)
-- --Guido van Rossum (home page: http://www.python.org/~guido/)