FileWrapper should be iterable

[jaroslavpachola]

If I understand the WSGI specification (PEP 3333) the file wrapper callable should return an iterable object - see https://peps.python.org/pep-3333/#optional-platform-specific-file-handling . I see GUnicorn can handle file wrapper another way (respiter discrimination), but when trying to use a WSGI app that depends on the iterable interface, the app breaks. Can we please add __iter__() to FileWrapper and fix this?

[pajod]

An object implementing the sequence protocol is also iterable, see https://docs.python.org/3/library/functions.html#iter
(the original WSGI spec was written at a time when Python 2.2 was still relevant)

Recommend you share in more detail as to why you think you have a use case for the other protocol, when the spec specifically demands all the precautions to ensure that this wrapper works when all middleware is not taking any special precautions, ignorant to the specific nature of the passed iterable object.

[jaroslavpachola]

An object implementing the sequence protocol is also iterable, see https://docs.python.org/3/library/functions.html#iter (the original WSGI spec was written at a time when Python 2.2 was still relevant)

Recommend you share in more detail as to why you think you have a use case for the other protocol, when the spec specifically demands all the precautions to ensure that this wrapper works when all middleware is not taking any special precautions, ignorant to the specific nature of the passed iterable object.

Thank you. The problem is the FileWrapper does not implement the iter protocol. It is used another way - GUnicorn detects type of "respiter" and if it is an instance of FileWrapper, its method wite_file() is called instead of the iterator.

In our case, we have an application that wraps environ['wsgi.file_wrapper'] in another iterator, which works in other wsgi implementations, namely mod_wsgi an uwsgi. We can, of course, change the app so that it returns environ['wsgi.file_wrapper'] directly, but we'd rather not as adding the iter protocol (as I unserstand it) is a part of the specification. And I see that GUnicorn can be more performant using the direct way, but it would not be affected by adding the __iter__() implementation for the other cases.

[pajod]

So what you really want is __iter__ to return self, which it is permitted to do, and which it happens to do almost anywhere, but afaict is just an implementation detail? As in: monkey-patching like makes your wrapper work across both types of trivial wrapper implementations?

if isinstance(file_wrapper, type) and not hasattr(file_wrapper, "__iter__"):
    class my_wrapper(file_wrapper):
        __nosuchkey = object()
        def __iter__(self): return self
        def __next__(self): return self.__getitem__(self.__nosuchkey)
else:
  my_wrapper = file_wrapper

I would suggest if Gunicorn adds these methods it also add the warning like stdlib wsgiref, if someone calls __getitem__ anyway (which really does not make much sense, given that this asks for an index.. then to be silently ignored), which would notify unsuspecting users meddling with internals like the above.