On Wed, Mar 28, 2012 at 4:30 PM, Masklinn 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 [-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: https://developers.google.com/appengine/docs/python/python27/using27#Configu... 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.

On 2012-03-28, at 21:13 , Terry Reedy wrote:

On 3/28/2012 7:37 AM, Masklinn wrote:

...

Currently, calling wsgiref.simple_server simply mounts the (bundled) demo app.

I think that's a bit of a lost opportunity: as the community has mostly standardized on a *.wsgi/wsgi.py script providing an `application` name in its global namespace, it would be nice if wsgiref.simple_server could take such a file as parameter and mount the application provided:

In my ignorance, this seems like a sensible request. If I understand correctly, you are not proposing to break any existing uses but to make this more useful without being overly specialized.

That would be the goal yes.

If you file an issue, Phillip Eby would probably be asked to review. The web-sig might be the best place to thrash out details and demonstrate 'community agreement'. A patch file, preferably with a test, along with a good text explanation, usually speeds disposition of an issue.

So you recommend I bring this over to web-sig, ideally alongside a patchfile? Will do, thank you for the suggestion.