At 05:04 AM 6/26/2005 -0600, Adam Olsen wrote: >On 6/26/05, Ronald Oussoren <[EMAIL PROTECTED]> wrote: > > Have a look at stackless python. http://www.stackless.com/ > >On 6/26/05, Florian Schulze <[EMAIL PROTECTED]> wrote: > > Also look at greenlets, they are in the py lib http://codespeak.net/py > >While internally Stackless and Greenlets may (or may not) share a lot >with my proposed python-native threads, they differ greatly in their >intent and the resulting interface they expose. Stackless and >Greenlets are both tools for building an architecture that uses >threads, while my python-native threads IS that resulting >architecture. > >For example, with Greenlets you would use the .switch() method of a >specific greenlet instance to switch to it, and with my python-native >threads you would use the global idle() function which would decide >for itself which thread to switch to.
See PEP 342 for a competing proposal, that includes a short (<50 lines) co-operative threading example. It uses the 'yield' keyword instead of your '@' proposal, and already has a Sourceforge patch implementing it. It does not propose a specific built-in idler or I/O handler, but such things could be added later. In the short term, I think it's enough that Python be *able* to have such things (without using Stackless or Greenlets), and maybe include an example of a run loop. I don't currently plan to push for a "standard" or "official" run loop implementation in Python 2.5, however, unless all the relevant stakeholders just happen to come to some kind of agreement that makes it happen. Note that while having a universal run loop is a worthy goal, actually implementing one is hard. The experts in this are definitely in the Twisted camp, as they have implemented run loops for numerous platforms to support compatibility w/various GUI frameworks' event loops. To some extent, this means that the run loop needs to be an interface with multiple implementations, and I think that we would need a standard library implementation of PEP 246 in order to support it properly. Anyway, my point is that even deciding on standards for a universal run loop is a fairly big project, one that possibly even deserves its own SIG to put together. By contrast, the implementation of simulated threads and non-blocking function calls was a weekend project. _______________________________________________ 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
