Change by Stéphane Wirtel : ---------- nosy: +mdk _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

STINNER Victor added the comment: I'm ok with modifying "make server" to reuse http.server, but I'm not sure about deprecating Tools/scripts/serve.py. serve.py uses wsgiref which is different than http.server. Does anyone use it? I would prefer to keep it. If you want to remove it, please send an email to python-dev to ask who uses it. "make serve" has been added by bpo-8004 which added Tools/scripts/serve.py. commit e4c74e1ea26e77b065a8999b7192160595474211 Author: Dirkjan Ochtman Date: Wed Feb 24 04:12:11 2010 +0000 Issue #8004: add a serve target to the Doc Makefile. ---------- nosy: +vstinner _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Julien Palard added the comment: If it's appreciated as a demo for wsgiref, wouldn't it be better to move it inside Doc/library/wsgiref.rst? It was written specifically for the Doc/Makefile, it's no longer needed for the Doc/Makefile, so the question pops: is it usefull to anyone? If not it's better to drop it (or move it to the documentation as a nice, time-proven example). ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Stéphane Wirtel added the comment: Hi @mdk and @brett with your suggestions, I will move the serve.py in the documentation of wsgiref and change Doc/Makefile. ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Change by Stéphane Wirtel : ---------- pull_requests: +12462 _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Change by Stéphane Wirtel : ---------- pull_requests: +12473 _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Brett Cannon added the comment: New changeset 360e1e4c519cfc139de707bcdd1e6c871eec79ee by Brett Cannon (Stéphane Wirtel) in branch 'master': bpo-36345: Add a new example in the documentation of wsgiref (#12511) https://github.com/python/cpython/commit/360e1e4c519cfc139de707bcdd1e6c871ee... ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

STINNER Victor added the comment: Would it me sense to use ".. literalinclude:: ../../Tools/scripts/serve.py" in the wsgi doc to keep serve.py and and this example up to date? It seems like serve.py is going to stay. ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Brett Cannon added the comment: I actually still think we should remove serve.py as the person who had needed to clean up that directory when we realized we had massive bitrot in /Tools. :) I don't' think that just because Debian packages means we need to continue supporting and maintaining it (e.g. if wsgiref was changed who is going to remember to update this script?). ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Change by Stéphane Wirtel : ---------- resolution: -> fixed stage: patch review -> resolved status: open -> closed _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Berker Peksag added the comment: Please revert 360e1e4c519cfc139de707bcdd1e6c871eec79ee. It's not a good example to put into the documentation. It uses different naming convention. It would only confuse users relatively new to the wsgiref module and WSGI protocol. FileWrapper was supposed to support __getitem__ and __iter__ protocols for compatibility with older Python versions, but its __getiem__ implementation is buggy and is already deprecated. It has no use case in modern Python code. It has zero exception handling and will return a cryptic traceback if mimetype cannot detect type of the file. The examples in the wsgiref documentation already cover most of the cases. There is no need to add more similar ones. ---------- nosy: +berker.peksag _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Berker Peksag added the comment:

I looked at other examples: they are nice but far from a "real application".

You can use the same argument for pretty much every example in the stdlib documentation :) wsgiref is a low level module, users should use projects like WebOb instead. Also, a complete example would need to contain basic routing and middleware support (which is not easy to implement correctly)

Would you mind to elaborate? I don't understand what you mean by "naming convention" here, sorry.

For example, the response() callable in the example is explicitly documented as start_response() in PEP 3333: https://www.python.org/dev/peps/pep-3333/#the-start-response-callable You can read PEP 3333 for more details.

Do you mean that app() must not return FileWrapper? How do you return file content in that case? Maybe FileWrapper API should be clarified? It's surprising to read Python 3.8 mentioning compatibility with Python 2.1 :-)

The whole point of the API was to support both __getitem__ and __iter__ protocols at the same time without breaking user code. I've already deprecated the support for __getitem__ protocol (84a13fbda0d79789e3c9efcc9f64752261ce1e8d) because it wasn't working as expected (it ignores its 'index' argument) Its only valid use case is to read a file chunk by chunk by using its blksize argument, but there are much better ways to achieve the same thing (use os.sendfile() or nginx :))

Which kind of exceptions do you expect? The example checks if the file exists for example.

I'm talking about exceptions that can be raised by the application code, such as the one that I've mentioned (i.e. mimetypes) in my earlier comment. Sorry, but it's not really a good example to put into documentation and it would be much better if we could save our bikeshedding bandwidth to other issues :) ---------- _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________

Change by Stéphane Wirtel : ---------- title: Deprecate Tools/scripts/serve.py in favour of python -m http.server -d -> Doc: make serve uses http.server instead of Tools/scripts/server.py _______________________________________ Python tracker https://bugs.python.org/issue36345 _______________________________________