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
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