Okay, thanks for all that. Now for next question.
So far we haven't addressed how wsgi.file_wrapper should work for
Python 3.0. Already in existing versions of Python usage of
wsgi.file_wrapper may be unclear in that there are portability
concerns between UNIX and Windows over fact that FILE objects do CRLF
translation on Windows. Thus the code:
f=open('/some/path/foo.txt','r')
length = os.fstat(f.fileno()).st_size
response('200 OK',[('Content-type',
'text/plain'),('Content-Length', str(length))])
return environ['wsgi.file_wrapper'](f)
will work okay on UNIX, but may yield wrong content length being sent
back to client on Windows. Technically this is even a problem without
wsgi.file_wrapper as use of:
if 'wsgi.file_wrapper' in environ:
return environ['wsgi.file_wrapper'](filelike, block_size)
else:
return iter(lambda: filelike.read(block_size), '')
is going to result in reads being done on translated file contents
rather than raw content that stat call done on.
Anyway, the solution here is obviously that files should be open as
'rb' (raw mode) and not 'r' if they want to be portable.
Now, on Python 3.0 if one opens a file in raw mode then when you read
data from the file it returns bytes whereas a read of normally opened
file returns strings.
How is wsgi.file_wrapper meant to behave in the face of this dual mode
of a file now in that it can return bytes or strings depending on how
it is opened? Do the same rules apply as you indicated before in that
when returning strings they should be translated to Latin-1?
Graham
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
