A question about the posibility of raise-yield in Python
in [Python]
|
Prev: git JSONRPC web service and matching pyjamas front-end
Next: how to ensure item in list or dict bind with "an uuid meaning" integer type ID?
From: Дамјан Георгиевски on 30 Jun 2010 03:13 > I'm writing this as a complete newbie (on the issue), so don't be > surprised if it's the stupidest idea ever. > > I was wondering if there was ever a discusision in the python > community on a 'raise-yield' kind-of combined expression. I'd like to > know if it was proposed/rejected/discussed/not-decided yet?? Recently (ok, several hours ago) I've come up to Greenlets [1] and it seems they implement exactly what I was asking for, in a C extension!! It's too bad that Python doesn't support this by default and many libraries won't make use of it by default. Gevent [2] for example, has to monkey-patch Python's socket, time.sleep and other modules so that things like urllib work with it. I'll continue to read now. [1] http://codespeak.net/py/0.9.2/greenlet.html [2] http://www.gevent.org/ > A 'raise-yield' expression would break the flow of a program just like > an exception, going up the call stack until it would be handled, but > also like yield it would be possible to continue the flow of the > program from where it was raise-yield-ed. > > This would be usefull for example in event based frameworks, they > could just replace socket.* and similar, normally blocking, > modules/functions with it's own 'raise-yield' enabled ones. > > Then you could just take any normal imperative code that calls normal > library networking code (say smtplib, poplib or httplib) nad run it in > a event framework. > The normal xxxlib calls at some point would get to the now > non-blocking, event based socket write/read, break the flow back to > the event framework, and when it finishes the event framework would > continue the normal flow of the program past the raise-yield. -- дамјан ((( http://damjan.softver.org.mk/ ))) Please remember 43% of statistics are made on the spot.
From: John Nagle on 30 Jun 2010 12:48 On 6/30/2010 12:13 AM, Дамјан Георгиевски wrote: >> A 'raise-yield' expression would break the flow of a program just like >> an exception, going up the call stack until it would be handled, but >> also like yield it would be possible to continue the flow of the >> program from where it was raise-yield-ed. Bad idea. Continuing after an exception is generally troublesome. This was discussed during the design phase of Ada, and rejected. Since then, it's been accepted that continuing after an exception is a terrible idea. The stack has already been unwound, for example. What you want, in in the situation you describe, is an optional callback, to be called in case of a fixable problem. Then the caller gets control, but without stack unwinding. John Nagle
From: rurpy on 30 Jun 2010 19:20 On Jun 30, 10:48 am, John Nagle <na...(a)animats.com> wrote: > On 6/30/2010 12:13 AM, ÐамÑан ÐеоÑгиевÑки wrote: > > >> A 'raise-yield' expression would break the flow of a program just like > >> an exception, going up the call stack until it would be handled, but > >> also like yield it would be possible to continue the flow of the > >> program from where it was raise-yield-ed. > >    Bad idea.  Continuing after an exception is generally troublesome. > This was discussed during the design phase of Ada, and rejected. > Since then, it's been accepted that continuing after an exception > is a terrible idea.  The stack has already been unwound, for example.. > >    What you want, in in the situation you describe, is an optional > callback, to be called in case of a fixable problem. Then the > caller gets control, but without stack unwinding. Strangely I was just thinking about something similar (non-stack the other day. Something like def caller(): try: callee() except SomeError, exc: ... else exclist: ... def callee(): if error: raise SomeError() else raise2: SomeWarning() raise2 would create an exception object but unlike raise, would save in it a list somewhere and when callee() returned normally, the list would be made asvailable to caller, possibly in a parameter to the try/except "else" clause as shown above. Obviously "raise2" is a placeholder for "some way to signal that this is a non-stack-unwinding exception." The use case addressed is to note exceptional conditions in a function that aren't exceptional enough to be fatal but which the caller may or may not care about. Siminlar to the Warning module but without the brokenness of doing io. Integrates well with the existing way of handling fatal exceptions. No idea if something like this even remotely feasible.
From: Carl Banks on 30 Jun 2010 23:40 On Jun 30, 12:13 am, ÐамÑан ÐеоÑгиевÑки <gdam...(a)gmail.com> wrote: > > I'm writing this as a complete newbie (on the issue), so don't be > > surprised if it's the stupidest idea ever. > > > I was wondering if there was ever a discusision in the python > > community on a 'raise-yield' kind-of combined expression. I'd like to > > know if it was proposed/rejected/discussed/not-decided yet?? > > Recently (ok, several hours ago) I've come up to Greenlets [1] and it > seems they implement exactly what I was asking for, in a C extension!! > > It's too bad that Python doesn't support this by default and many > libraries won't make use of it by default. Gevent [2] for example, has > to monkey-patch Python's socket, time.sleep and other modules so that > things like urllib work with it. > > I'll continue to read now. Ah, if I had seen your original post I probably could have pointed you to some good reading right away. What you've described is called a continuation, and is natively supported by some languages (like Scheme). It's usually not done with exceptions, though. In Scheme it's a special form that looks like an ordinary function call, but you can "return" from the call any number of times. A while back, Stackless Python supported continuations, but it was removed because (IIRC) it made stackless too platform-dependent (plus there wasn't much interest). Carl Banks
From: Ryan Kelly on 1 Jul 2010 02:16
On Wed, 2010-06-30 at 16:20 -0700, rurpy(a)yahoo.com wrote: > On Jun 30, 10:48 am, John Nagle <na...(a)animats.com> wrote: > > On 6/30/2010 12:13 AM, Дамјан Георгиевски wrote: > > > > >> A 'raise-yield' expression would break the flow of a program just like > > >> an exception, going up the call stack until it would be handled, but > > >> also like yield it would be possible to continue the flow of the > > >> program from where it was raise-yield-ed. > > > > Bad idea. Continuing after an exception is generally troublesome. > > This was discussed during the design phase of Ada, and rejected. > > Since then, it's been accepted that continuing after an exception > > is a terrible idea. The stack has already been unwound, for example. > > > > What you want, in in the situation you describe, is an optional > > callback, to be called in case of a fixable problem. Then the > > caller gets control, but without stack unwinding. I've tried my hand at implementing the "condition/handler/restart" paradigm of common lisp, which is very similar to what you describe. You might find it useful: http://pypi.python.org/pypi/withrestart/ Cheers, Ryan -- Ryan Kelly http://www.rfk.id.au | This message is digitally signed. Please visit ryan(a)rfk.id.au | http://www.rfk.id.au/ramblings/gpg/ for details |