> My concern is that you will end up with vastly more 'yield from's > than places that require locks, so most of them are just noise. > If you bite your nails over whether a lock is needed every time > you see one, they will cause you a lot more anxiety than they > alleviate.
Not necessarily. The yield from's follow the blocking control flow, which is surprisingly less common than you might think. Parts of your code naturally arise as not requiring blocking behaviour in the same manner as in Haskell where parts of your code are identified as requiring the IO monad. >> Sometimes there's no alternative, but wherever I can, I avoid thinking, >> especially hard thinking. This maxim has served me very well throughout my >> programming career ;-). I'd replace "hard thinking" with "future confusion" here. > There are already well-known techniques for dealing with > concurrency that minimise the amount of hard thinking required. > You devise some well-behaved abstractions, such as queues, and > put all your hard thinking into implementing them. Then you > build the rest of your code around those abstractions. That > way you don't have to rely on crutches such as explicitly > marking everything that might cause a task switch, because > it doesn't matter. It's my firm belief that this isn't sufficient. If this were true, then the Python internals could be improved by replacing the GIL with a series of channels/queues or what have you. State is complex, and without guarantees of immutability, it's just not practical to try to wrap every state object in some protocol to be passed back and forth on queues. _______________________________________________ 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