cgitb.py for Python 2.2
Hi guys. Sorry i've been fairly quiet recently -- at least life isn't dull. I wanted to put in a few words for cgitb.py for your consideration. I think you all saw it at IPC 9 -- if you missed the presentation, there are examples at http://www.lfw.org/python to check out. What i'm proposing is that we toss cgitb.py into the standard library (pretty small at about 100 lines, since all the heavy lifting is in pydoc and inspect). Then we can add this to site.py: if os.environ.has_key("GATEWAY_INTERFACE"): import sys, cgitb sys.excepthook = cgitb.excepthook I think this is pretty safe, since GATEWAY_INTERFACE is guaranteed to exist under the CGI specification and should never appear in any other context. cgitb.py is written in paranoid fashion -- if anything goes wrong during generation of the HTML traceback, sys.stderr still goes to the browser; and if for some reason the page gets dumped to a shell somewhere, the original traceback is still visible in a comment at the end of the page. The upside is that we *automagically* get pretty tracebacks for all the Python CGI scripts there, with zero effort from the CGI script writers. I think this is a really strong hook for people getting started with Python. No more "internal server error" messages followed by the annoying task of inserting "print 'Content-Type: text/html\n\n<pre>'" into all your scripts! As for me, i've probably done this hundreds of times now, and would love to stop doing it. I anticipate a possible security concern (as this shows bits of your source code to strangers when problems happen). So i have tried to address that by providing a SECRET flag in cgitb that causes the tracebacks to get written to files instead of the Web browser. Opinions and suggestions are welcomed! (I'm looking at the good stuff that the WebWare people have done with it, and i plan to merge in their improvements. For the HTML-heads out there in particular, i'm looking for your thoughts on the reset() routine.) -- ?!ng
Ka-Ping Yee <ping@lfw.org>:
The upside is that we *automagically* get pretty tracebacks for all the Python CGI scripts there, with zero effort from the CGI script writers. I think this is a really strong hook for people getting started with Python.
<boggle>I've been to look at the cgitb page. My jaw dropped open.</boggle> +1 -- <a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a> The abortion rights and gun control debates are twin aspects of a deeper question --- does an individual ever have the right to make decisions that are literally life-or-death? And if not the individual, who does?
"KY" == Ka-Ping Yee <ping@lfw.org> writes:
KY> What i'm proposing is that we toss cgitb.py into the standard KY> library (pretty small at about 100 lines, since all the heavy KY> lifting is in pydoc and inspect). Then we can add this to KY> site.py: No time right now to look at it, but I remember it looked pretty cool at IPC9. I'd like to merge in some of the ideas I've developed in Mailman's driver script, which prints out the environment and some other sys information. driver always prints to a log file and optionally to stdout (it has a STEALTH_MODE variable that's probably equivalent to your SECRET). One thing I tried very hard to do was to make driver bulletproof, so that it only imported a very minimal amount of stuff, and that /any/ exception along the way would get caught and not allowed to percolate up out of the top frame (which would cause a non-zero exit status and unhelpful message in the browser). About the only thing that isn't caught are exceptions importing sys, but if that happens you have bigger problems! :) I'll take a closer look at cgitb.py when I get a chance, but I'm generally +1 on the idea. -Barry
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
"AK" == Andrew Kuchling <akuchlin@mems-exchange.org> writes:
AK> +0 from me, though I also think it would be better in cgi.py AK> and not in site.py. It would also be useful if it could mail AK> tracebacks and return a non-committal but secure error message AK> to the browser; I'll contribute that as a patch if cgitb.py AK> goes in. (Or should that be cgi/tb.py? Hmm...) Whatever happened to PEP 222? :)
Sorry i've been fairly quiet recently -- at least life isn't dull.
You still have a few SF bugs and patches assigned! How about addressing those?!
I wanted to put in a few words for cgitb.py for your consideration.
I think you all saw it at IPC 9 -- if you missed the presentation, there are examples at http://www.lfw.org/python to check out.
Yeah, it's cool.
What i'm proposing is that we toss cgitb.py into the standard library (pretty small at about 100 lines, since all the heavy lifting is in pydoc and inspect). Then we can add this to site.py:
if os.environ.has_key("GATEWAY_INTERFACE"): import sys, cgitb sys.excepthook = cgitb.excepthook
Why not add this to cgi.py instead? Th site.py initialization is accumulating a lot of cruft, and I don't like new additions that are irrelevant for most apps (CGI is a tiny niche for Python IMO). (I also think all the stuff that's only for interactive mode should be moved off to another module that is only run in interactive mode.) --Guido van Rossum (home page: http://www.python.org/~guido/)
"GvR" == Guido van Rossum <guido@zope.com> writes:
>> What i'm proposing is that we toss cgitb.py into the standard >> library (pretty small at about 100 lines, since all the heavy >> lifting is in pydoc and inspect). Then we can add this to >> site.py: if os.environ.has_key("GATEWAY_INTERFACE"): import >> sys, cgitb sys.excepthook = cgitb.excepthook GvR> Why not add this to cgi.py instead? Th site.py GvR> initialization is accumulating a lot of cruft, and I don't GvR> like new additions that are irrelevant for most apps (CGI is GvR> a tiny niche for Python IMO). (I also think all the stuff GvR> that's only for interactive mode should be moved off to GvR> another module that is only run in interactive mode.) 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. -Barry
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
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.
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. 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? 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? -- ?!ng
Ka-Ping Yee <ping@lfw.org>:
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
On Tue, Jul 31, 2001 at 10:06:27PM -0400, Eric S. Raymond wrote:
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.
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) Damn, I'm a traitor to my own language. Simon
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/)
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! --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
On Fri, Aug 03, 2001 at 08:33:40AM -0400, Guido van Rossum wrote:
But Ping's tracebackhook still shouldn't be the default.
Yep, understood.
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.
How about making it the default iff certain CGI-oid enviroment variables are set? Or would that be way too magical? Simon
"SC" == Simon Cozens <simon@netthink.co.uk> 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
Barry A. Warsaw wrote:
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
OTOH, looking for a CGITB variable might work. On the gripping hand, anyone who wants to work it that way can do so with two lines of code. -- --- Aahz (@pobox.com) Hugs and backrubs -- I break Rule 6 <*> http://www.rahul.net/aahz/ Androgynous poly kinky vanilla queer het Pythonista I don't really mind a person having the last whine, but I do mind someone else having the last self-righteous whine.
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
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. Let's have the cgitb module as an optional feature. Let's update various documentation to suggest this boilerplate at the top of CGI modules: import cgi import cgitb; cgitb.enable() Regarding the secrecy of tracebacks: normal tracebacks are seen by a user who has logged in to the system and who can look at the source code anyway. Web tracebacks can be seen as invitations to hackerz without any source access to look for weaknesses in the script. That's a very different thing from a security point of view! (Security by obscurity, maybe, but nevertheless better than hanging out your dirty laundry to dry in public. Enough hackerz know Python.) --Guido van Rossum (home page: http://www.python.org/~guido/)
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
On 03 August 2001, Guido van Rossum said:
it though, so that CGI scripts can use
#!/usr/bin/env python -C
as their first line.
Completely off-topic: the "/usr/bin/env" hack doesn't work with command-line arguments under Linux: $ cat t.py #!/usr/bin/env python -i print "hello" $ ./t.py /usr/bin/env: python -i: No such file or directory 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). Greg -- Greg Ward - Python bigot gward@python.net http://starship.python.net/~gward/ "What do you mean -- a European or an African swallow?"
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 Sat, 4 Aug 2001, Greg Ward <gward@python.net> wrote:
Completely off-topic: the "/usr/bin/env" hack doesn't work with command-line arguments under Linux:
$ cat t.py #!/usr/bin/env python -i
print "hello"
$ ./t.py /usr/bin/env: python -i: No such file or directory
That's what POSIX mandates, IIRC. Blame UNIX for using such an ugly hack for shebang lines. It's probably better to use #!/usr/bin/python and use binfmt_misc under linux with the correct echo > something/in/proc magic to alias it to the correct interpreter. -- Moshe Zadka - http://moshez.geek (if you're not cool, http://moshez.org is still working)
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/)
On Tue, 31 Jul 2001, Guido van Rossum wrote:
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.
Sorry that i misunderstood. This sounds reasonable to me (though it seems your opinions may have changed since you wrote this).
I don't want Python to become a wannabe CGI language [...] 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.
This attitude surprised me a little and sounded somewhat sad. "Perl is the established standard"? Aw. I say if people want a better tool, they should use it. The fact that Perl has more users than Python doesn't make us give up on Python for system administration or text processing or database access, even though Perl can do all these things. The fact is Python's quite good. :)
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).
I guess i have a hard time seeing the "detriment" part. What great detriment to others is being caused here, by a feature that only affects CGI to begin with? -- ?!ng
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
Ka-Ping Yee wrote: [Guido]
Why not add this to cgi.py instead?
Because that would seem to defeat most of the point.
[snip]
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?
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?
Web stuff is certainly a major doorway. Not sure about cgi.py itself. Web stuff accounts for (very, very roughly) 20% of what I do. I have never used cgi.py. In fact, the only web related module in the std lib I use regularly is urllib (mostly for the quote stuff). So neither site.py nor cgi.py would do me any good. (In fact, cgitb.py wouldn't either, since my source is not on the server and sys.std* have nothing to do with requests/responses). Judging by the list at http://www.paul.boddie.net/Python/web_modules.html I don't think I'm all that unusual in this regard. (BTW, line 133 should be filename = tempfile.mktemp('.html') ). - Gordon
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 <thomas@xs4all.net> Hi! I'm a .signature virus! copy me into your .signature file to help me spread!
Thomas Wouters wrote:
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 [...]
I wouldn't either. Doing an import and/or a function is not too hard. I'm -1 on magically enabling Ping's traceback thing (cool as it is). Neil
>> 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
"SM" == Skip Montanaro <skip@pobox.com> writes:
SM> I have to agree. Perhaps just as significant, what would SM> happen to a CGI script that already attempts to do something SM> to direct error output to a file or mail message the webmaster SM> will see? That's my major concern about enabling by default too. I'd now have to have a way to /disable/ it explicitly, but of course, I'd have to wrap that in a try/except in case I'm using an older cgi.py. SM> Most of my users wouldn't know a traceback (simpler or SM> otherwise) from a hole in the ground. I think I have perhaps SM> two users who would understand that I was trying to create a SM> more readable report. I agree. cgitb.py is without a doubt Very Cool and should definitely be in the std library. But it's of use only to a handful of people, primarily the developers of cgi module-based scripts. +1 on additing it to std library +1 on turning it on only with an explicit action (although I could live with enabling via side-effect on import of cgitb.py, count me -0 for that). -Barry
+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/)
participants (16)
-
aahz＠rahul.net -
Andrew Kuchling -
barry＠zope.com -
David Ascher -
Eric S. Raymond -
Fred L. Drake, Jr. -
Gordon McMillan -
Greg Ward -
Guido van Rossum -
Ka-Ping Yee -
Michel Pelletier -
Moshe Zadka -
Neil Schemenauer -
Simon Cozens -
Skip Montanaro -
Thomas Wouters