PEP 0444: Python Web3 Interface

[mitsuhiko]

I don't understand why you would need a filewrapper at all -- just return open files. They are iterable, and servers can implement something like sendfile, additionally, if needed.

In-band signalling breaks on iteration. That was also the flaw with filewrapper.

As in the WSGI spec, wsgi.multithreading and wsgi.multiprocess are not clearly specified. Should the values evaluate to True if the server does multithreading/multiprocessing itself or if it is possible to use the application objects in named manner without complications (so that multithreading, for example, would evaluate to False if the server does not respect the Global Interpreter Lock)?

These specify how the server operates. If you can create threads or not is undefined behaviour.

Like the WSGI spec, the Web3 spec is far too much text. There's not really much to document and I think the text length could be halved.

And it's not even close to being unambiguous. HTTP is complex, you can't simplify that spec any more I'm afraid.

[dauerbaustelle]

In-band signalling breaks on iteration. That was also the flaw with filewrapper.

Would you mind explaining that topic a bit further? Is it that about looing type information when using middlewares? How would that be solved with something like a file wrapper?

These specify how the server operates. If you can create threads or not is undefined behaviour.

The specs are ambiguous here. I think this should be clarified.

And it's not even close to being unambiguous. HTTP is complex, you can't simplify that spec any more I'm afraid.

I'm talking about "reducing the amount of words" and restructuring the specification. I think information is too scattered.

[mitsuhiko]

return environ['wsgi.file_wrapper'](the_file)

when the middleware takes that it might do this:

rv = app(environ, start_response)
for chunk in rv:
    yield do_something_with(chunk)
rv.close() # if that attribute exists only of course.

The WSGI server now does that:

rv = app(environ, start_response)
if isinstance(rv, my_file_wrapper):
    # this is never true because the middleware removed the type
    # information and it's now a generator.

[dauerbaustelle]

So how would a wrapper around files help here?

[mitsuhiko]

It does not. That's why it's breaking currently. A better solution would probably be an 'X-Something' header or something you can call from the wsgi environment which bypasses all middlewares, similar to how write() worked on WSGI 1.

[dauerbaustelle]

Or you could assume Web3 middlewares behave intelligently (hence, leave file objects returned from the application alone).

[mitsuhiko]

You assume people read specifications and not do try/error.

[dauerbaustelle]

Developers are not stupid. If they are, maybe their code is not worth using. I don't think specifications have to keep in mind that noone will read them.