[Python-Dev] Re: [Stackless] comments on PEP 219

[Gordon McMillan]

Greg Ewing wrote:

> Gordon McMillan <gmcm@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 
__init__, too.
 
> >  - 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 
done).
 
> > 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.]

- Gordon