[Jeremy] > Here are some comments on Gordon's new draft of PEP 219 and the > stackless dev day discussion at Spam 9. > > I left the dev day discussion with the following takehome > message: There is a tension between Stackless Python on the one > hand and making Python easy to embed in and extend with C > programs on the other hand. The PEP describes this as the major > difficulty with C Python. I won't repeat the discussion of the > problem there. Almost all of the discussion about interpreter recursions is about completeness, *not* about usability. If you were to examine all the Stackless using apps out there, I think you would find that they rely on a stackless version of only one builtin - apply(). I can think of 2 practical situations in which it would be *nice* to be rid of the recursion: - magic methods (__init__, __getitem__ and __getattr__ in particular). But magic methods are a convenience. There's absolutely nothing there that can't be done another way. - a GUI. Again, no big deal, because GUIs impose all kinds of restrictions to begin with. If you use a GUI with threads, you almost always have to dedicate one thread (usually the main one) to the GUI and be careful that the other threads don't touch the GUI directly. It's basically the same issue with Stackless. As for the rest of the possible situations, demand is nonexistant. In an ideal world, we'd never have to answer the question "how come it didn't work?". But put on you application programmers hat for a moment and see if you can think of a legitimate reason for, eg, one of the objects in an __add__ wanting to make use of a pre-existing coroutine inside the __add__ call. [Yeah, Tm can come up with a reason, but I did say "legitimate".] > I would like to seem a somewhat more detailed discussion of this > in the PEP. I think it's an important issue to work out before > making a decision about a stack-light patch. I'm not sure why you say that. 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. [Mark doesn't even claim to know *how* he solved the problem <wink>]. > The problem of nested interpreters and the C API seems to come up > in several ways. These are all touched on in the PEP, but not in > much detail. This message is mostly a request for more detail > :-). > > - Stackless disallows transfer out of a nested interpreter. > (It > has, too; anything else would be insane.) Therefore, the > specification for microthreads &c. will be complicated by a > listing of the places where control transfers are not > possible. The PEP says this is not ideal, but not crippling. > I'd like to see an actual spec for where it's not allowed in > pure Python. It may not be crippling, but it may be a > tremendous nuisance in practice; e.g. remember that __init__ > calls create a critical section. The one instance I can find on the Stackless list (of attempting to use a continuation across interpreter invocations) was a call the uthread.wait() in __init__. Arguably a (minor) nuisance, arguably bad coding practice (even if it worked). I encountered it when trying to make a generator work with a for loop. So you end up using a while loop <shrug>. It's disallowed where ever it's not accomodated. Listing those cases is probably not terribly helpful; I bet even Guido is sometimes surprised at what actually happens under the covers. The message "attempt to run a locked frame" is not very meaningful to the Stackless newbie, however. [Christian answered the others...] - Gordon
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4