[Python-ideas] A more useful command-line wsgiref.simple_server?

[Masklinn]

On 2012-03-28, at 15:03 , anatoly techtonik wrote:
>> Since wsgiref already supports `python -mwsgiref.simple_server`, the
>> change would be pretty simple:
> 
> Is it possible to choose a more intuitive name if it is for Python 3.3
> only anyway?

The wsgiref module has not changed on that point in Python 3
(wsgiref.simple_server is still wsgiref.simple_server), so adding
behavior would be done to the same place.

>> * the first positional argument is the wsgi script
>>  if it is present it is `exec`'d, the `application` key is
>>    extracted from the locals and is mounted through make_server;
>>  if it is absent, then demo_app is mounted as before
>> * the second positional argument is the host, defaulting to ''
>> * the third positional argument is the port, defaulting to 8000
> 
> To summarize:
> python -m wsgiref.simple_server [[wsgi_script.py] [[host] [port]]]

actually,

    python -m wsgiref.simple_server [wsgi_script [host [port]]]

> 
> A better way:
> python -m wsgiref.simple_server <wsgi_script[.py][:application]> [-h
> host] [-p port]

>    <wsgi_script[.py][:application]>

I don't think that is a good idea:

1. WSGI scripts don't have to have any extension or can have no
extension at all (as far as I can tell, many scripts follow mod_wsgi by
using a .wsgi extension)
2. Not sure why the application name would be editable, this adds
needless complexity and it does not seem supported by the most populat
deployment method (mod_wsgi)
3. Finally, this changes the current behavior mounting the demo app by
default, which I'd rather not do unless stdlib maintainers assert it
should be done.

So just [wsgi_script]

>   [-h host] [-p port]

I'd rather not burn help's -h for host specification. Are there really so
many situations where you'd want to specify a port and leave the default
host?

>> This way the current sanity test/"PHPInfo" demo app works as it did before,
>> but it becomes possible to very easily serve a WSGI script with almost no
>> overhead in the script itself.
>> 
>> Thoughts?
> 
> 1. Even more awesome if any WSGI application could be tested
> (bootstrapped) this way.

Well as far as I can tell, most WSGI applications which can work
single-threaded would work with just that.