On 10:18 pm, t...@urandom.ca wrote:
On Wed, 2009-09-23 at 22:07 +0000, exar...@twistedmatrix.com wrote:
Sure, no value judgement intended, except on the practice of taking
words with well established meanings and re-using them for something
else ;)
I think it's the behaviour that's important, and not the specific
syntax
needed to implement that behaviour.
In other words, I disagree (if this is what you're suggesting) that
sticking "yield" in front of certain expressions makes it any less a
coroutine.
Alright, I won't pretend to have any particular insight into what the
fundamental "coroutineness" of a coroutine is.
To me, the difference I outlined in this thread is important because it
is a difference that is visible in the API (almost if it were some
unusual, extra part of the function's signature) to application code. If
you have a "send" function that is what I have been calling a "real"
coroutine, that's basically invisible. Put another way, if you started
with a normal blocking "send" function, then applications would be using
it without "yield". If you used "real" coroutines to make it
multitasking-friendly, then the same applications that were already
using it would continue to work (at least, they might). However, if you
have something like Python's enhanced generators, then they all break
very obviously, since "send" no longer returns the number of bytes
written, but now returns a generator object, something totally
different.
Now, I would say that this there's not a huge amount of value in being
able to make a function into a coroutine behind the application's back.
All kinds of problems can result from this. Others will certainly
disagree with me and say that it's worth more than the cost of the
trouble it might cause. But either way, there's clearly *some*
difference between the "real" coroutine way and the enhanced generators
way.
If you think that's not an important difference, I don't mind. I just
hope I've made it clear why I initially said that enhanced generators
aren't what a lot of people would call coroutines. :)
Now, requiring explicit yields does mean that the coroutine has
specific, well-defined points of reentry. But I don't believe it's a
necessary condition that coroutines allow arbitrary (in the
non-deterministic sense) reentry points, only multiple.
I don't think "non-deterministic" is the right word to use here; at
least, it's not what I was trying to convey as possible in coroutines.
More like "invisible".
That aside, I do think that most people familiar with coroutines from
outside of Python would disagree with this, but I haven't don't a formal
survey or anything, so perhaps I'm mistaken.
Jean-Paul
--
http://mail.python.org/mailman/listinfo/python-list
