Is Stackless Python DEAD?

[Martin von Loewis]

Michael Abbott <michael at rcp.co.uk> writes:

> I would have thought that the nature of the beast is likely to require 
> quite substantial modifications to key parts of Python.
> 
> Can you describe what you mean by "intrusive" in this context?

The patches changes nearly everything in the core interpreter, and it
is not clear whether all these changes are really necessary and for
the better.

It *is* clear that some things just cannot continue to work as they
did. Is just isn't clear (to me) that all the complexity that the
stackless patch adds is really necessary.

It's been quite some time since I studied it last, so here's what I
found after a quick glance right now:
- it adds 17 new members to the frame object, doubling the number
  of members. Usage of some of these members isn't obvious to me.
- It adds a field nesting_level to the thread state, without
  ever checking its value (it just counts the nesting level)
- it adds a number of _nr variants of functions (non-recursive),
  e.g. for map and eval. In __builtins__, the _nr versions are
  available as "map" and "eval", while the original versions are
  preserved as apply_orig and map_orig:
  * Are the _nr versions functionally completely backwards-compatible?
    If not, why? If yes, why is the original version preserved?
  * Just to implement map, 150 lines of builtin_map had to be
    rewritten into 350 lines (builtin_map, make_stub_code,
    make_map_frame, builtin_map_nr, builtin_map_loop). The author
    indicates that the same procedure still needs to be done for
    apply and filter. Just what is the "same procedure"? Isn't there
    some better way?
- The code adds PREPARE macros into each branch of ceval. Why?
- It adds a long list of explicitly not-supported opcodes into
  the ceval switch, instead of using 'default:'. No explanation
  for that change is given, other than 'unused opcodes go here'.
  Is it necessary to separately maintain them? Why?

It may be that some of these questions can be answered giving a good
reason for the change, but I doubt that this code can be incorporated
as-is, just saying "you need all of this for Stackless Python". I
don't believe you do, but I cannot work it out myself, either.

Regards,
Martin