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

Wed Mar 28 15:30:21 CEST 2012

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.