Martin v. Löwis wrote:
My point is that Stackless 3.0 is probably not acceptable for integration into C Python because of the processor-specific assembler fragments.
Ok, that can be dropped and put into an extension.
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.
I didn't understand the question this way, although it was probably meant so. For me it was more like "why doesn't it aim for Stackless' features". Although I'm trying to make Stackless as clean and compatible as possible, I'm not trying to have my current version ready for inclusion. Development is more influenced by user requests.
I think, the heart of the thing is to decide whether Python wants to go the way to make as much as possible calls non-recursive. This is a lot of work, and I did one possible implementation, which minimized changes to the rest of the system. If we try to modify Python to be stackless, we would probably got more rigorous ways and change more of the design. I can't do that alone. I doubt that anybody would be able to create such a re-design alone, while keeping up with Python development, that does quite much in the opposite direction. This must become a goal of the core developer group.
all the best - chris