Is Stackless Python DEAD?
Martin von Loewis
loewis at informatik.hu-berlin.de
Mon Nov 5 21:01:31 CET 2001
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
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.
More information about the Python-list