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

Thu Mar 29 00:38:15 CEST 2012

On Wed, Mar 28, 2012 at 4:30 PM, Masklinn <masklinn at masklinn.net> wrote:
> 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.

I can't see why it can not be something like:
 python -m wsgiref ...
Making wsgiref provide a server is an intuitive guess. Non-intuitive
part is that running `wsgiref` doesn't give a hint where to find this
server.
>    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)

All right. Let's drop [.py]
> 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)

I don't use `mod_wsgi` deployment, and can't confirm your popularity rating.
I use AppEngine - it uses `app` in example:
https://developers.google.com/appengine/docs/python/python27/using27#Configuring_WSGI_Script_Handlers
gunicorn uses `app` also:
http://pypi.python.org/pypi/gunicorn
 `wsgiref` doesn't place any restriction on callable name, so why
hardcode it to `application`. Let it do discovery itself or make the
callable name explicit (you know - it's better).
> 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]

Well, makes sense, but how do you know that server_example has
parameters? It may be better to leave a --demo argument if somebody
needs a demo.
>>   [-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?

I forgot that -h is for --help. `-H host[:port]` may be a better
notation, indeed, for consistency with fabric. And there are really
many situations where I have AppEngine already running on port 8000.
Ideally port should be auto chosen from the first that is free above
8000 if not specified explicitly.
>> 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.

You still have to hardcode callable name to `application`. It still
would be nice to have some autodetection logic.
-- 
anatoly t.