<div class="gmail_quote">On Fri, Mar 30, 2012 at 2:22 PM, Sasha Hart <span dir="ltr">&lt;<a href="mailto:s@sashahart.net">s@sashahart.net</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">I do really like the idea of having a quick WSGI runner in the stdlib,</div></blockquote><div><br></div><div>What&#39;s kind of funny is that this was actually one of the original use cases that resulted in the invention of WSGI; back in the early 2000&#39;s, PEAK had its own internal protocol called &quot;runCGI&quot;, and part of the idea was that we had a command line tool that could run things implementing that interface from the command line, with servers for fastcgi, cgi, SimpleHTTPServer, and so on.</div>
<div><br></div><div>Ah well, that&#39;s a bit off-topic.  But mainly, it&#39;s the reason I never got thought of actually making wsgi_ref.simple_server actually do that stuff; I already had a runner in PEAK that would do that kind of thing and launch a browser too.  Despite inspiring simple_server, it completely slipped my mind that it&#39;d be a good idea to put that stuff in wsgiref, too!</div>
<div><br></div><div>Regarding modules vs. files, I don&#39;t really care that much which way the capability is spelled, as long as the file vs. module distinction is explicit.  &quot;-m &quot; isn&#39;t a lot to add to a command line, and neither is &quot;-f &quot;.  If there&#39;s no consensus, just require that one or the other be specified, and inconvenience both groups of people equally.  ;-)</div>
<div><br></div></div>