A question about the posibility of raise-yield in Python

[Дамјан ГеоргиевÑки]

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??


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.

 

[Terry Reedy]

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??

The idea of resumable exceptions has been discussed and so far rejected.
I presume the cost in complication of both the language and
implementations is seen as too high.

 

[Lie Ryan]

The idea of resumable exceptions has been discussed and so far rejected.
I presume the cost in complication of both the language and
implementations is seen as too high.

I once proposed a similar construct a couple of years ago (it was also
one of my first post in this group)
http://groups.google.com/group/comp...ad/thread/ac62e0fe69304c6f/ec95518c16e8b9dc?q

And also, in the last few weeks (or so), there was a thread in
python-ideas mailing list proposing "yieldfrom":

yieldfrom iterable

is equivalent to:

for n in iterable:
yield n

which is practically the same as what I was and raise-yield is
proposing. The difference being that SoftException/raise-yield silently
re-raise the exception, while yieldfrom is an explicit re-raise.

 

[Дамјан ГеоргиевÑки]

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/

 

[John Nagle]

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

 

[rurpy]

     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.

 

[Carl Banks]

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

 

[Ryan Kelly]

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

 

[Дамјан ГеоргиевÑки]

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.

I thought they were called coroutines?

Anyway, here's the Lua implementation of coroutines. It's basically a
yield but it will return back several frames.

http://lua-users.org/wiki/CoroutinesTutorial

 

[Thomas Jollans]

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.

I thought they were called coroutines?

The scheme call-with-current-continuation facility is a lot more
powerful than python generator-coroutines or, I expect, than whatever it
is that Lua has.

In Python, you can return to a "yield" expression exactly once, then the
code continues, and the state is lost. In Scheme, you can pass the state
around, save it, and return there as often as you want. Kind of
"go-back-to-this-particular-frame-state" as opposed to
"go-back-into-that-(co)routine"

Everything that you can do with the coroutine facilities in languages
like Python, Ruby, and Lua, Scheme's call/cc allows you to do as well.

Thomas