Martin von Loewis <loewis at informatik.hu-berlin.de> writes:
[schnipp]
> It's been quite some time since I studied it last, so here's what I
> found after a quick glance right now:
Did you actually want answers to these questions? It's been sometime
since I looked at it, but think I can remember the answer to some of
them. Take a pinch of salt with most of what follows.
> - 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.
See below about map & friends.
> - It adds a field nesting_level to the thread state, without
> ever checking its value (it just counts the nesting level)
I imagine this was just for bragging with :)
> - 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?
I think the originals are just around because the implementation of
the _nr variants was tricky and Chris needed something to test
against. Not sure, though.
> * 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?
This is where implementing stackless in C really, really hurts.
To get continuations to work (the way stackless does it anyway, there
are other tricks), you need to allocate your locals on the (C) heap
(it is called stackless, after all). This is no problem for Python
code (as Python has heap-allocated its locals forever).
So when map wants to call the Python function, it needs to stuff all
the local data it cares about into a frame object (see above), push
this frame object onto the (Python) stack, *return* to the interpreter
in such a way that the mapping function is called next and then every
time(!) that returns have the interpreter call back into map again.
So in the map case, I think builtin_map_nr is called first, which
calls make_map_frame specifying that the interpreter should return
into builtin_map_loop, shoves the resulting frame onto the stack, then
returns. The interpreter than calls builtin_map_loop, which if the
lists mapping over are exhausted, pops the "fake" frame off the stack
and returns (which means the interpreter carries on with the code that
called map), or just returns again.
I don't remember what make_stub_code is for.
Is this helping? Oh well...
> - 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?
This was an optimization Chris used to try and get back some of the
performance lost during the stackless changes. IIRC, he handles
exceptions and return values as "pseudo-opcodes" rather than using the
WHY_foo constants the current ceval.c uses. I never really understood
this part.
> 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.
I think integrating stackless into the core is a fairly huge amount of
work. I'd like to think I could do it, given several months of
full-time effort (which isn't going to happen). About the only likely
way I see for it to get in is for it to become important to Zope
Corp. for some reason, and them paying Tim or Guido (or Chris) to do
it.
Cheers,
M.
--
Never meddle in the affairs of NT. It is slow to boot and quick to
crash. -- Stephen Harris
-- http://home.xnet.com/~raven/Sysadmin/ASR.Quotes.html