[Python-Dev] Traceback problem

[Christian Tismer]

Guido van Rossum wrote:
> [Guido]
> 
>>>I believe that Stackless supports Python 2.1 or older, and we're not
>>>adding features.  Even if Stackless supported Python 2.2, adding a new
>>>feature would be iffy.

I am not talking about adding a feature but removing a wart.

> [Christian]
> 
>>Huh? What makes you believe that?
> 
> 
> I thought quite a while ago you announced you were giving up the old
> stackless code.  I must have misunderstood.

And introduced the new, much better, Stackless code, of course.
This is what I'm talking about at PyCon. You were in the comittee.

>>I'm talking of 2.3, of course.
> 
> 
> But without GC, right?  Or did I misunderstand that too?  I thought
> you told me that your customers didn't want GC enabled?  But in 2.3 GC
> can't be disabled.  So I guess I'm unclear on what you want.

I have asked them about GC. Both were less negative about GC than
they claimed a year ago. But this is not the point.

The code they have cannot be made working by GC, since there
is a life cycle supported by prolonged survival of exceptions
that cannot be solved by GC. There is *no* way to clear
an exception other than raising another one, or by leaving
the current function that received the exception.
Since it is easy to catch an exception in the except clause
my assingning sys.exc_info() to some locals, there is no
need to make these implicitly survive longer than needed,
with the extra surprize that there is no sane way to
clean them up.

...

> It's pretty complex to explain the actual behavior, so I gave a
> recipe that's a little more restricted but is guaranteed to work.

It is actually quite simple to explain, since I know almost
all of ceval.c by heart:

There is only one single function in the whole system that both
clears the exception saved in tstate, *and* the extra reference
which is captured in the current frame:

It is reset_exc_info(), a static local function in ceval.c,
which is exactly only called when eval_frame returns.

>>Where I have to say that I'm in favor of doing like
>>the documentation claims.
> 
> 
> Too bad, that would definitely break existing code.

Break it, break it! Code that does not adhere to the
documentation is bad code that should be broken,
even if it is your own. Examplify.
Relying on side effects which are not documented
have *never* been an argument for you to support abuse.

> [And later, Guido]
...

> Who reads documentation. :-)

You, I suppose. :-)

...

> You and Kevin Jacobs can argue about the syntax.

Proposals, in decreasing orders of delight:

1) Implement exeptions according to the documentation.
    Cleaning exceptions after they are handled is what
    most users would expect, last but not least since
    the documentation suggests it.

2) Add an optional boolean clear argument to sys.exc_info()
    This is lame, but it gives the user one way out.

3) Add an extra reset_exp function to sys.
    More lame since it requires an extra function,
    just to patch a "feature".

4) Keep things as they are, and expect the Spanish Inquision.

In case of 4), I assure you to start a thread that will
not be less than the PEP308 mess. In the other cases,
I will happily submit a validated patch.

Please don't disappoint me by defending a questionable design.

sincerely your's -- chris

-- 
Christian Tismer             :^)   <mailto:tismer@tismer.com>
Mission Impossible 5oftware  :     Have a break! Take a ride on Python's
Johannes-Niemeyer-Weg 9a     :    *Starship* http://starship.python.net/
14109 Berlin                 :     PGP key -> http://wwwkeys.pgp.net/
work +49 30 89 09 53 34  home +49 30 802 86 56  pager +49 173 24 18 776
PGP 0x57F3BF04       9064 F4E1 D754 C2FF 1619  305B C09C 5A3B 57F3 BF04
      whom do you want to sponsor today?   http://www.stackless.com/