[Python-Dev] Stackless Python

["Martin v. Löwis"]

Christian Tismer wrote:
>>> I'm believe that map and filter are non-recursive
> 
> 
> They have been. They can be, again, but why.

I'm not saying they should be non-recursive; I was just claiming
that they weren't, and that they would trigger "hard" switching.

> I don't know the C++ exception mechanism. It it walks the whole stack
> once before taking an action, then this is a problem.
> If it does proper unwinding of C frames, I could probably play the
> game and restore things just in time.

I'm unsure also; this is part of the Visual C++ runtime (or perhaps
even of the system's "structured EH"). In my coroutine library, the
application would crash even if there was an exception handler that
could have been found without walking the entire stack.

> Anyway, I don't really get the point.
> 95% of Stackless is doing soft-switched stackless calls.

My point is that Stackless 3.0 is probably not acceptable for
integration into C Python because of the processor-specific
assembler fragments.

> The discussion, as often before, tries to find out why it is *not*
> possible to include Stackless, instead of finding out the useful
> parts which could be supported with relatively small impact.
> This is why Stackless exists, and will continue to exist.

That's because people always ask the question "Can it be included?"
They never ask "If I were to contribute this and that part, would
it be accepted?".

Actually, this thread *started* with the question "Why isn't Python
stackless?" to which the correct answer is "Because nobody has
contributed patches." Only then people get excited and think that
Stackless 3.0 would be part of Python 2.5.

Regards,
Martin