Python 2.0 and Stackless

[Michael Hudson]

Ah, you are listening :-)

Christian Tismer <tismer at appliedbiometrics.com> writes:

> Michael Hudson wrote:
> > 
> > "Jeff Petkau" <jpet at eskimo.com> writes:
> > 
> > > For normal Python programs (that don't use stackless or uthreads),
> > > the *only* effect of the stackless patch is to make Python faster
> > > and more crash-resistant (since you can't overflow the C stack).
> > 
> > Hmm, only "sort-of".  I mean, yes, you won't overflow the C stack, but
> > unbounded recursion is still a bug; with stackless you'll just sit
> > there allocating frames until you chew through all available VM and
> > then bomb out with a MemoryError (and spend about a day printing the
> > traceback) - or segfault (Python isn't brilliant in low memory
> > situations).
> 
> No problem. Thenext version includes a sys variable that controls
> the maximum allowed recursion level. I'm further thinking of
> a way to compress tracebacks in such a situation, since 10000
> tracebacks scolling over your screen makes no sense.

Fair enough.  But infinite recursion is still a bug.  I don't have a
stackless python built ATM, but does

class Crasher:
 def __str__(self): print self

print Crasher()

get caught by stackless?  *Most* forms of infinite recursion don't
crash the current implementation.  Some do, and IMHO that's a bug.

> > > So it's a complete win, no downside.
> > 
> > It makes the implementation more complex.  This is a real downside.
> > That said, I think I'm in favour of it going in - it's just *cool*,
> > and that's what I like about Python.  Sod technical arguments <wink>.
> 
> Thanks for your opinion.
> While I don't agree that the implementation is really more
> complex. 

s/complex/further from what people are used to and thus harder to
understand and modify for the bulk of the programming community/ then.

> First, it is already written and proved stable.

I wasn't claiming it wasn't!

> Second, not the implementation is complex, but rethinking frames,
> recursion and stacks.

Which I claim makes some parts of the implementation (eg. builtin_map)
more complicated.  I think it's cleaner in some conceptual ways, but
because you're implementing it in C you have to jump through a variety
of hoops to get what you want.

> This is no issue about changing a little code, it is about changing
> brains.

Indeed!

Any chance of a patch against a recent CVS?

Cheers,
Michael

-- 
81. In computing, turning the obvious into the useful is a living
    definition of the word "frustration".
  -- Alan Perlis, http://www.cs.yale.edu/homes/perlis-alan/quotes.html