[Python-Dev] Re: [Stackless] comments on PEP 219
gmcm at hypernet.com
Wed Mar 14 16:08:16 CET 2001
> >>>>> "GMcM" == Gordon McMillan <gmcm at 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
> "Python is a language in which the use of uthreads in a module
> you didn't know existed can render your own program unusable."
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.
-eat-human-flesh-<munch, munch>-ly y'rs
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless