Is Stackless Python DEAD?

[Martin von Loewis]

Michael Hudson <mwh at python.net> writes:

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

If they are all just for the variables in map etc., a better solution
must be found - don't think it is desirable to have them in every
frame, if they are just used inside map.

However, from inspecting the patch, I doubt this is the case. Some of
them are general-purpose, but I couldn't easily figure out what, for
example, this first-instruction business is good for.

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

Why couldn't map behave as if it was a plain Python function,
implemented as

def map(fun,args):
  res = []
  for a in args:
    res.append(fun(a))

[I know that map is implemented in a more-involved way; it should
still be possible to find its Python equivalent, then think how
stackless would execute this equivalent]

For the additions to frame_state, that would mean that map should
reserve a number of localsplus variables, instead of outright adding
to frame_state on the C level.

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

If it is an optimization, I think we should take a step back and first
try to understand what it tries to optimize, and how it does
that. Perhaps we find that it isn't needed at all, and that the
problem could be solved in a different way. If you don't understand
it, it can't go into Python.

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

I don't think these are the options. I don't volunteer to support this
code myself, either, but if somebody would step forward and claim that
she understands it all, and is willing to present it to Guido in a way
that he understands it also, and if all the hackish parts of it would
be replaced by understandable code, I think it could go into Python.
It just needs a determined volunteer to work on it.

Regards,
Martin