[Python-ideas] A more useful command-line wsgiref.simple_server?
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
> 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]
> 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:
gunicorn uses `app` also:
`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
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.
More information about the Python-ideas