[Python-Dev] Re: [Stackless] comments on PEP 219
gmcm at hypernet.com
Wed Mar 14 03:55:44 CET 2001
Greg Ewing wrote:
> Gordon McMillan <gmcm at hypernet.com>:
> > But magic methods are a convenience. There's
> > absolutely nothing there that can't be done another way.
> Strictly speaking that's true, but from a practical standpoint I
> think you will *have* to address __init__ at least, because it is
> so ubiquitous and ingrained in the Python programmer's psyche.
> Asking Python programmers to give up using __init__ methods will
> be greeted with about as much enthusiasm as if you asked them to
> give up using all identifiers containing the leter 'e'. :-)
No one's asking them to give up __init__. Just asking them
not to transfer control from inside an __init__. There are good
reasons not to transfer control to another thread from within an
> > - a GUI. Again, no big deal
> Sorry, but I think it *is* a significantly large deal...
> > be careful that the other threads don't
> > touch the GUI directly. It's basically the same issue with
> > Stackless.
> But the other threads don't have to touch the GUI directly
> to be a problem.
> Suppose I'm building an IDE and I want a button which spawns a
> microthread to execute the user's code. The thread doesn't make
> any GUI calls itself, but it's spawned from inside a callback,
> which, if I understand correctly, will be impossible.
For a uthread, if it swaps out, yes, because that's an attempt
to transfer to another uthread not spawned by the callback. So
you will get an exception if you try it. If you simply want to
create and use coroutines from within the callback, that's fine
(though not terribly useful, since the GUI is blocked till you're
> > The one comparable situation
> > in normal Python is crossing threads in callbacks. With the
> > exception of a couple of complete madmen (doing COM support),
> > everyone else learns to avoid the situation.
> But if you can't even *start* a thread using a callback,
> how do you do anything with threads at all?
Checking the couple GUIs I've done that use threads (mostly I
use idletasks in a GUI for background stuff) I notice I create
the threads before starting the GUI. So in this case, I'd
probably have a worker thread (real) and the GUI thread (real).
The callback would queue up some work for the worker thread
and return. The worker thread can use continuations or
uthreads all it wants.
My comments about GUIs were basically saying that you
*have* to think about this stuff when you design a GUI - they
all have rather strong opinions about how you app should be
architected. You can get into trouble with any of the
techniques (events, threads, idletasks...) they promote / allow
/ use. I know it's gotten better, but not very long ago you had
to be very careful simply to get TK and threads to coexist.
I usually use idle tasks precisely because the chore of
breaking my task into 0.1 sec chunks is usually less onerous
than trying to get the GUI to let me do it some other way.
[Now I'll get floods of emails telling me *this* GUI lets me do it
*that* way... As far as I'm concerned, "least worst" is all any
GUI can aspire to.]
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless