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

Gordon McMillan 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
>   capabilities.

[Jeremy] 
> 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 
callbacks. 

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 
extension writer.


> Jeremy
> 
>     [*] 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>?

- Gordon
_______________________________________________
Stackless mailing list
Stackless at starship.python.net
http://starship.python.net/mailman/listinfo/stackless



More information about the Stackless mailing list