<br><div class="gmail_quote">On Fri, Mar 30, 2012 at 3:31 AM, Masklinn <span dir="ltr">&lt;<a href="mailto:masklinn@masklinn.net">masklinn@masklinn.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">On 2012-03-30, at 04:25 , PJ Eby wrote:<br>
&gt;<br>
&gt;&gt; (B) use --file=c:\app.py or similar to disambiguate what kind of<br>
&gt;&gt; parsing to do - then the typical case can be the importable and users<br>
&gt;&gt; who really want to refer to files explicitly can do so<br>
&gt;<br>
&gt; This is my preference if we do support both - to explicitly separate<br>
&gt; modules from scripts somehow.<br>
<br>
</div>Earlier I proposed a -m switch (inspired from Python), although the<br>
repetition of -m may be slightly weird I think it could work nicely.<br>
<br>
In either case, the colon separator would be removed and the<br>
application&#39;s variable name would be a positional following the<br>
script-or-module.<br></blockquote></div><br><br>I am finding more reasons to dislike that -m:<br><br>    python -m wsgiref.simple_server -m blog app<br><br>Beyond looking a little stuttery, it&#39;s really unclear. Anyone could be forgiven for thinking that -m meant the same thing in both cases, took the same kinds of arguments, could be exchanged for any other -m clause. But wsgiref.simple_server is not at all doing what Python is doing so I see no gain of understanding by reusing the convention. python -m doesn&#39;t take a second positional argument, either. You can&#39;t write &#39;-m blog app -m wsgiref.simple_server&#39; or &#39;-m blog -m wsgiref.simple_server blog&#39;, but you have to understand lots of specifics to see why. I think it&#39;s just too confusing.<br>

<br>On reflection, I feel strongly that a module name should be the default positional arg, not a filename. I agree with PJ Eby that pointing directly at a file encourages script/module confusion. I would add that it encourages hardcoding file paths rather than module names, which is brittle and not good for the WSGI world (for example, it bypasses virtualenvs and breaks any time a different deploy directory structure is used). Of course, this also means no &#39;-m&#39;. Then the typical use case is really just<br>

<br>    python -m wsgiref.simple_server blog<br><br>A second positional arg is both a new convention and not an explicit one, where I would prefer either an existing implicit convention or a new explicit one. <br><br>I think PJ Eby is right that the colon convention is only for modules, and I think following gunicorn&#39;s lead here would result in a nicer interface than forcing (say) --module<br>

<br>    python -m wsgiref.simple_server blog:app<br><br>If there is a need to point at a filename, I agree that it should be done explicitly.  <br><br>    python -m wsgiref.simple_server --file=~/app.py<br><br>(or whatever the flag should be called). To me this seems like a small cost to allow the colon by default without possibility of confusion or overly fancy parsing.<br>

<br>I do really like the idea of having a quick WSGI runner in the stdlib, I hope it happens and would be happy to help. New users should be able to see results with a one-liner local server and a quick server deploy tutorial BEFORE they have to implement a WSGI recipe or understand WSGI. Although it&#39;s not rocket science, it&#39;s just easier for everyone when people who don&#39;t (yet) care about WSGI aren&#39;t forced to deal with it directly, and this would help a little with that.<br>