[Python-Dev] Re: cgitb.py for Python 2.2

Ka-Ping Yee ping@lfw.org
Fri, 3 Aug 2001 23:45:05 -0700 (PDT)


Hi all,

I'm glad this is being discussed, and i understand that some of you
are concerned about changing default behaviour, but, uh, it kind of
irks me that the major concerns aren't that well based in truth.

Thomas Wouters wrote:
> You might not want people to edit scripts, but I'm not sure howmany
> people want the functionality of their CGI script(s) significantly
> changed without editing their scripts.

Skip Montanaro wrote:
> I have to agree.  Perhaps just as significant, what would happen to a CGI
> script that already attempts to do something to direct error output to a
> file or mail message the webmaster will see?

Nothing!  It would still work.  No functionality would change at all!

That's the whole point.  This feature only kicks in at the point
where a program has ALREADY FAILED.  By definition, there is nothing
the program could have done at that point.  It's about to die.

Barry Warsaw wrote:
> I'm concerned about magically enabling it, because then my existing
> cgi scripts have to be modified to turn it off or they will/might
> break.

They *couldn't* break.  I mean, they could only "break" in the case
where they're already broken.

There seems to be this general nervousness about making a change,
but -- well, i don't really see what you all are going on about.
It seems to me that if you think about it for a bit, you'll see
why the change couldn't break anything.

If anything is there (e.g. some sort of CGI-imitation environment)
running the script and catching exceptions, then there's no issue.
sys.excepthook is only a last resort.

Setting os.environ['GATEWAY_INTERFACE'] after the program starts
doesn't magically install the feature -- it's only enabled if the
GATEWAY_INTERFACE variable is present when Python starts, which
can only be the case if the caller of the Python binary wants the
script to behave like a CGI script, and cgitb meets that contract.

Skip Montanaro wrote:
> Most of my users wouldn't know a traceback (simpler or otherwise) from a
> hole in the ground.  I think I have perhaps two users who would understand
> that I was trying to create a more readable report.

It is certainly a legitimate concern that you may want to keep
your tracebacks secret.

However, this seems to be just as good an argument that ordinary
Python programs shouldn't print tracebacks on stderr.  Oh, no --
what if a user sees them?

Well, the user saw it because something went wrong.  Of course
you don't want a typical user to worry about tracebacks.  If your
program was correct, that would never happen.  When you do get one,
something truly exceptional has occurred.  And yet we do display
tracebacks on stderr nevertheless, because

    You Never Know An Error Is About To Happen Before It Happens.

And when it does happen, gosh! am i ever grateful i got that traceback.


-- ?!ng