[Stackless] Re: [Python-Dev] comments on PEP 219
gmcm at hypernet.com
Tue Mar 13 19:29:56 CET 2001
> >>>>> "CT" == Christian Tismer <tismer at tismer.com> writes:
> CT> Maybe I'm repeating myself, but I'd like to clarify: I do
> not CT> plan to introduce anything that forces anybody to
> change her CT> code. This is all about extending the current
> The problem with this position is that C code that uses the old
> APIs interferes in odd ways with features that depend on
> stackless, e.g. the __xxx__ methods.[*] If the old APIs work but
> are not compatible, we'll end up having to rewrite all our
> extensions so that they play nicely with stackless.
I don't understand. Python code calls C extension. C
extension calls Python callback which tries to use a pre-
existing coroutine. How is the "interference"? The callback
exists only because the C extension has an API that uses
Well, OK, the callback doesn't have to be explicit. The C can
go fumbling around in a passed in object and find something
callable. But to call it "interference", I think you'd have to have
a working program which stopped working when a C extension
crept into it without the programmer noticing <wink>.
> If we change the core and standard extensions to use stackless
> interfaces, then this style will become the standard style. If
> the interface is simple, this is no problem. If the interface is
> complex, it may be a problem. My point is that if we change the
> core APIs, we place a new burden on extension writers.
This is all *way* out of scope, but if you go the route of
creating a pseudo-frame for the C code, it seems quite
possible that the interface wouldn't have to change at all. We
don't need any more args into PyEval_EvalCode. We don't
need any more results out of it. Christian's stackless map
implementation is proof-of-concept that you can do this stuff.
The issue (if and when we get around to "truly and completely
stackless") is complexity for the Python internals
programmer, not your typical object-wrapping / SWIG-swilling
> [*] If we fix the type-class dichotomy, will it have any
> effect on the stackful nature of some of these C calls?
Don't know. What will those calls look like <wink>?
Stackless mailing list
Stackless at starship.python.net
More information about the Stackless