Corey Coughlin <[EMAIL PROTECTED]> writes: > Mike Meyer wrote: >> Calls to methods of a separate object are non-blocking. The calls are >> queued, and executed later. Reading an attribute from a separate >> object is a blocking action. Calling a method with a separate object >> as an argument causes the call to block until the separate arguments >> are all locked. There are rules - enforceable by the compiler - about >> what you can do with separate objects that prevent a lot of the things >> that cause headaches when doing concurrent programming. > Undoubtedly enforced by contracts, Eiffel is nice that way.
Actually, no. "separate" is a property of a variable, and certain things you can do with normal variables you can't do with separate variables. The semantics of contracts do enter into things, though. When you pass a separate variable to a function, the function blocks until the separate variable is available, and all the preconditions that mention it are true. This gives you gaurded semaphores. > Yeah, the dynamic nature of python makes a straight translation of > SCOOP pretty problematic. But it's good stuff to consider, > definitely some great ideas in there. I'm not really sure I want a > solution that gets as complicated as SCOOP, but it may not be > something I can avoid. Ah well, some thinking to do. But just out > of curiosity, would you support a PEP with some language additions > to support and simplify concurrency? I'm certainly interested in seeing such a thing done to Python. Whether I'd support a specific PEP would depend on the PEP. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list