On Sat, Feb 23, 2019 at 5:32 AM Juancarlo Añez <apal...@gmail.com> wrote: > On Thu, Feb 21, 2019 at 11:32 PM Chris Angelico <ros...@gmail.com> wrote: >> >> On Fri, Feb 22, 2019 at 2:27 PM Juancarlo Añez <apal...@gmail.com> wrote: >> > Then, if exceptions are going to be part of a type, there should be a way >> > to express the semantics of them (like in Eiffel), so >> > stack.pop();stack.push(x) doesn't have to catch StackFullException. >> > >> >> That assumes atomicity. If you want an atomic "replace top of stack" >> that can never raise StackFullException, it's probably best to express >> it as stack.replacetop(x) rather than having something that might be >> interrupted. > > Ah! What to do with an exception in a concurrent context? Abort, or retry > after a while?
You mean in a situation where another thread might be pushing/popping on the same stack? That's up to you. Exception handling works exactly the same way with multiple threads as it does with a single thread; each context has a call stack. Things are a bit more complicated with other forms of concurrency, but at the point where there is an execution context again, that's where exceptions can start bubbling again. That's how generators work, for instance. ChrisA _______________________________________________ Python-ideas mailing list Python-ideas@python.org https://mail.python.org/mailman/listinfo/python-ideas Code of Conduct: http://python.org/psf/codeofconduct/
