On Mon, Jul 30, 2001 at 11:04:03PM -0400, Barry A. Warsaw wrote:

I'll take a closer look at cgitb.py when I get a chance, but I'm generally +1 on the idea.

+0 from me, though I also think it would be better in cgi.py and not in site.py. It would also be useful if it could mail tracebacks and return a non-committal but secure error message to the browser; I'll contribute that as a patch if cgitb.py goes in. (Or should that be cgi/tb.py? Hmm...) --amk

On Tue, 31 Jul 2001, Barry A. Warsaw wrote:

I'm at best +0 on adding it to site.py too. E.g. for performance reasons Mailman's cgi wrappers invoke Python with -S to avoid the expensive overhead of importing site.py for each cgi hit.

This is just one environment variable check -- doesn't touch the disk at all. Most of site.py's time is spent scanning paths and such, i believe. -- ?!ng

Ka-Ping Yee :

I think this is where our perceptions differ. I think of CGI as the application that totally "made" Perl, and as the quickest, easiest way that many beginners get early payoff from a scripting language. My impression is that it has been a big "hook" for bringing people to Perl and Python -- it's the shortest path to building and deploying something useful to a huge and unlimited audience.

I strongly agree with Ping on this. My experience is that CGI is an extremely important application category for Python, and one worth significant effort to serve. -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> Good intentions will always be pleaded for every assumption of authority. It is hardly too strong to say that the Constitution was made to guard the people against the dangers of good intentions. There are men in all ages who mean to govern well, but they mean to govern. They promise to be good masters, but they mean to be masters. -- Daniel Webster

I also strongly agree. CGI's one application that draws a lot of people into programming, and many of them for the first time - you get a lot of web designers and the like wanting to go a bit further, and it'd be nice to get them into the good kind of snake (Python) instead of the bad kind of snake. (ASP)

OK. CGI is important. But Ping's tracebackhook still shouldn't be the default. I'm willing to entertain a new command line option for it though, so that CGI scripts can use #!/usr/bin/env python -C as their first line. --Guido van Rossum (home page: http://www.python.org/~guido/)

Guido van Rossum wrote:

...

I'm willing to entertain a new command line option for it though, so that CGI scripts can use

#!/usr/bin/env python -C

as their first line.

But it's fine to require making a call to cgi.whatever() too, and that's certainly a lot less work!

Furthermore, I believe that it's not always easy to get web servers to respect command line options set in shebang lines, so my guess is that doing cgi.whatever() is going to work for more people (e.g. people who have CGI access but not webserver config access). --david

...

...

...

...

"SC" == Simon Cozens writes:

>> I'm willing to entertain a new command line option for it >> though, so that CGI scripts can use #!/usr/bin/env python -C as >> their first line. SC> How about making it the default iff certain CGI-oid enviroment SC> variables are set? Or would that be way too magical? 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. And I'll have to conditionalize the code to turn them off in case my users have an older version of Python. explicit-is-better-than-implicit-ly y'rs, -Barry

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

On Sat, 4 Aug 2001, Guido van Rossum wrote:

Give it up, Ping. cgitb writes the tb to stdout, not to stderr, and that's enough of a difference in behavior to require explicit enabling. It's not worth your energy to try and convince us.

Okay. I defer to your sense of judgement. (My last message was composed before i read your message quoted above.) -- ?!ng

Greg Ward writes:

Grumble. Andrew and I tried to track this down once, and found suspicious-looking code in the kernel (ie., I don't think it's the fault of GNU env).

I had always understood that the sh-bang line could only provide a single argument to begin with. I don't know what you found in the kernel sources, but I'd expect it to be implementing that policy. So /usr/bin/env gets one parameter from the sh-bang line, "python", and then another parameter added by the kernel: the name of the script. Sounds about right to me. Whether we like the constraint that there be only one arg from the sh-bang line doesn't really matter; lots of systems enforce this constraint, so to be portable we need to live with it. -Fred -- Fred L. Drake, Jr. <fdrake at acm.org> PythonLabs at Zope Corporation

On Tue, 31 Jul 2001, Guido van Rossum wrote:

...

Why not add this to cgi.py instead?

Because that would seem to defeat most of the point.

The point was to provide an instant, effortless improvement for all of the Python CGI scripts out there. If programmers have to manually edit all of their CGI scripts to insert

import sys, cgitb sys.excepthook = cgitb.excepthook

then it's just as annoying as inserting

import sys sys.stderr = sys.stdout

I don't want people to have to edit every single script.

You misunderstand. You proposed a few lines that would automatically do this in site.py, which is always imported. I propose to add those same lines to cgi.py, so that any code that imports cgi.py *automatically* has he feature enabled. I assume that all CGI scripts have an import of cgi. There are non-CGI scripts that import cgi, but those will be protected by the check for an environment variable that you propose.

...

I don't like new additions that are irrelevant for most apps (CGI is a tiny niche for Python IMO).

I think this is where our perceptions differ. I think of CGI as the application that totally "made" Perl, and as the quickest, easiest way that many beginners get early payoff from a scripting language.

Yeah. But it's not doing that for Python IMO. Most Python apps (even those that do web stuff) are not CGI apps.

My impression is that it has been a big "hook" for bringing people to Perl and Python -- it's the shortest path to building and deploying something useful to a huge and unlimited audience.

Wouldn't you say there are more Python CGI programmers out there than, say, Zope developers? Or think of it like this: what fraction of Web developers are CGI programmers, and what fraction of those use Python?

I don't want Python to become a wannabe CGI language, and I don't want to make choices that benefit CGI programmers to the detriment of others (CGI is actually a pretty lame way of producing active web content). Python is a decent language for CGI, but Perl is the established standard and then there's PHP which also has way more users than Python.

Maybe i'm wrong? I welcome more opinions from others -- how do you see people coming to Python? What's the first "real" thing they do with Python that motivates them to try it?

All sorts of stuff. Using NumPy. GUI apps. Database apps. Unix scripting. App steering. --Guido van Rossum (home page: http://www.python.org/~guido/)

Ka-Ping Yee wrote:

The point was to provide an instant, effortless improvement for all of the Python CGI scripts out there. If programmers have to manually edit all of their CGI scripts to insert

import sys, cgitb sys.excepthook = cgitb.excepthook

then it's just as annoying as inserting

import sys sys.stderr = sys.stdout

But Zope would have to do: import sys _sys_excepthook = sys.excepthook from cgi import FieldStorage, escape sys.excepthook = _sys_excepthook and I don't think we'd be the only one that would have to do that. Zope has the environment variable set when accessed from CGI, but its stderr gets redirected to a log file for plain text human consumption. importing cgi would have an unintended side effect. I would prefer an explicit interface than a side effect. +1 on it being in the standard lib, or course. -Michel

On Tue, Jul 31, 2001 at 06:23:39PM -0700, Ka-Ping Yee wrote:

On Tue, 31 Jul 2001, Guido van Rossum wrote:

...

Why not add this to cgi.py instead?

Because that would seem to defeat most of the point.

The point was to provide an instant, effortless improvement for all of the Python CGI scripts out there. If programmers have to manually edit all of their CGI scripts to insert

I don't want people to have to edit every single script.

I'm sorry, Ping, but I have to disagree with you there... 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. I know I wouldn't, even though nothing would break; I wouldn't feel comfortable displaying the innards of some of the CGI scripts to whoever manages to feed it faulty data. I would strongly suggest making people add a single line, along the lines of cgi.enable_debug() or cgi.install_reporter() and doing the exception-hook replacement in there. -- Thomas Wouters Hi! I'm a .signature virus! copy me into your .signature file to help me spread!

>> I don't want people to have to edit every single script. Thomas> I'm sorry, Ping, but I have to disagree with you there... You Thomas> might not want people to edit scripts, but I'm not sure howmany Thomas> people want the functionality of their CGI script(s) Thomas> significantly changed without editing their scripts. 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? 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. Skip

+1 on additing it to std library +1 on turning it on only with an explicit action (although I could

Agreed.

live with enabling via side-effect on import of cgitb.py, count me -0 for that).

-1 on enabling it with "import cgitb". Modules with import side effects are evil (and trickier to introspect, as Ping should know :-). --Guido van Rossum (home page: http://www.python.org/~guido/)