<html><head></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><div><div>On Jan 18, 2012, at 4:23 AM, Mark Shannon wrote:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div>Glyph wrote:<br><blockquote type="cite">On Jan 17, 2012, at 5:03 PM, Mark Shannon wrote:<br></blockquote><blockquote type="cite"><blockquote type="cite">Lets start controversially: I don't like PEP 380, I think it's a kludge.<br></blockquote></blockquote><blockquote type="cite">Too late; it's already accepted. There's not much point in making controversial statements about it now.<br></blockquote><br>Why is it too late?</div></blockquote><div><br></div><div>Because discussion happens before the PEP is accepted. See the description of the workflow in <<a href="http://www.python.org/dev/peps/pep-0001/">http://www.python.org/dev/peps/pep-0001/</a>>. The time to object to PEP 380 was when those threads were going on.</div><br><blockquote type="cite"><div>Presenting this as a fait accompli does not make it any better.</div></blockquote><div><br></div><div>But it <i>is</i>[1] a fait accompli, whether you like it or not; I'm first and foremost informing you of the truth, not trying to make you feel better (or worse). Secondly, I am trying to forestall a long and ultimately pointless conversation :).</div><div><br></div><blockquote type="cite"><div>The PEP mailing list is closed to most people,</div></blockquote><div><br></div><div>The PEP mailing list is just where you <i>submit</i> your PEPs, and where the PEP editors do their work. I'm not on it, but to my understanding of the process, there's not really any debate there.</div><br><blockquote type="cite"><div>so what forum for debate is there?<br></div></blockquote><div><br></div><div>python-ideas, and then this mailing list, in that order. Regarding PEP 380 specifically, there's been quite a bit. See for example <<a href="http://thread.gmane.org/gmane.comp.python.devel/102161/focus=102164">http://thread.gmane.org/gmane.comp.python.devel/102161/focus=102164</a>>. Keep in mind that the purpose of debate in this context is to inform Guido's opinion. There's no voting involved, although he will occasionally delegate decisions about particular PEPs to people knowledgeable in a relevant area.</div><div><br></div><blockquote type="cite"><div><blockquote type="cite">I think this discussion would be more suitable for python-ideas though [...]</blockquote>Already been discussed:<br><a href="http://mail.python.org/pipermail/python-ideas/2011-October/012571.html">http://mail.python.org/pipermail/python-ideas/2011-October/012571.html</a><br></div></blockquote><div><br></div><div>If you're following the PEP process, then the next step would be for you (having built some support) to author a new PEP, or to resurrect the deferred Stackless PEP with some new rationale - personally I'd recommend the latter.</div><div><br></div><div>My brief skimming of the linked thread doesn't indicate you have a lot of strong support though, just some people who would be somewhat interested. So I still think it bears more discussion there, especially on the motivation / justification side of things.</div><div><br></div><blockquote type="cite"><div>All of the objections to coroutines (as I propose) also apply to PEP 380.<br></div></blockquote><div><br></div><div>You might want to see the video of Guido's "Fireside Chat" last year <<a href="http://pycon.tv/#/video/100">http://pycon.tv/#/video/100</a>>. Skip to a little before 15:00. He mentions the point that coroutines that can implicitly switch out from under you have the same non-deterministic property as threads: you don't know where you're going to need a lock or lock-like construct to update any variables, so you need to think about concurrency more deeply than if you could explicitly always see a 'yield'. I have more than one "painful event in my past" (as he refers to it) indicating that microthreads have the same problem as real threads :).</div><div><br></div><div>(And yes, they're microthreads, even if you don't have an elaborate scheduling construct. If you can switch to another stack by making a function call, then you are effectively context switching, and it can become arbitrarily complex. Any coroutine in a system may introduce an arbitrarily complex microthread scheduler just by calling a function that yields to it.)</div><div><br></div><div>-glyph</div><div><br></div><div><div>([1]: Well actually it isn't, note the dashed line from "Accepted" to "Rejected" in the workflow diagram. But you have to have a really darn good reason, and championing the rejection of a pep that Guido has explicitly accepted and has liked from pretty much the beginning is going to be very, very hard.)</div><div><br></div><blockquote type="cite"></blockquote></div></div></body></html>