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

anatoly techtonik techtonik at gmail.com
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.



More information about the Python-ideas mailing list