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

[Gordon McMillan]

[Jeremy]
> >>>>> "GMcM" == Gordon McMillan <gmcm@hypernet.com> writes:
> 
>   >> Is this the semantic difference between Stackless and
>   CPython >> that people are getting all in a lather about?
> 
>   GMcM> What semantic difference? You can't transfer control to a
>   GMcM> coroutine / urthread in a magic method in CPython, either
>   GMcM> <wink>.
> 
> If I have a library or class that uses threads under the covers,
> I can create the threads in whatever code block I want,
> regardless of what is on the call stack above the block.  The
> reason that coroutines / uthreads are different is that the
> semantics of control transfers are tied to what the call stack
> looks like a) when the thread is created and b) when a control
> transfer is attempted.

Just b) I think.
 
> This restriction seems quite at odds with modularity.  (Could I
> import a module that creates a thread within an __init__ method?)
>  The correctness of a library or class depends on the entire call
> chain involved in its use.

Coroutines are not threads, nor are uthreads. Threads are 
used for comparison purposes because for most people, they 
are the only model for transfers of control outside regular call / 
return. My first serious programming language was IBM 
assembler which, at the time, did not have call / return. That 
was one of about 5 common patterns used. So I don't suffer 
from the illusion that call / return is the only way to do things.

In some ways threads make a lousy model for what's going 
on. They are OS level things. If you were able, on your first 
introduction to threads, to immediately fit them into your 
concept of "modularity", then you are truly unique. They are 
antithetical to my notion of modularity.

If you have another model outside threads and call / return, 
trot it out. It's sure to be a fresher horse than this one.
 
> It's not at all modular, because a programmer could make a local
> decision about organizing a particular module and cause errors in
> a module that don't even use directly.  This would occur if
> module A uses uthreads, module B is a client of module A, and the
> user writes a program that uses module B.  He unsuspectingly adds
> a call to module A in an __init__ method and *boom*.

You will find this enormously more difficult to demonstrate 
than assert. Module A does something in the background. 
Therefor module B does something in the background. There 
is no technique for backgrounding processing which does not 
have some implications for the user of module B. If modules A 
and or B are poorly coded, it will have obvious implications for 
the user.

> "Python is a language in which the use of uthreads in a module
> you didn't know existed can render your own program unusable." 
> <wink>

Your arguments are all based on rather fantastical notions of 
evil module writers pulling dirty tricks on clueless innocent 
programmers. In fact, they're based on the idea that the 
programmer was successfully using module AA, then 
switched to using A (which must have been advertised as a 
drop in replacement) and then found that they went "boom" in 
an __init__ method that used to work. Python today has no 
shortage of ways in which evil module writers can cause 
misery for programmers. Stackless does not claim that 
module writers claiming full compatiblity are telling the truth. If 
module A does not suit your needs, go back to module AA.

Obviously, those of us who like Stackless would be delighted 
to have all interpreter recursions removed. It's also obvious 
where your rhetorical argument is headed: Stackless is 
dangerous unless all interpreter recursions are eliminated; it's 
too much work to remove all interpreter recursions until Py4K; 
please reassign this PEP a nineteen digit number.

and-there-is-NO-truth-to-the-rumor-that-stackless-users
-eat-human-flesh-<munch, munch>-ly y'rs

- Gordon