On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:
Alice Bevan-McGregor <al...@...> writes:
GothAlice: ... native string usage, the definition of "byte string" as
"the format returned by socket read" (which, on Java, is unicode!) ...
Just so no-one feels the need to correct me; agronholm made sure I
didn't drink the kool-aid of one article I was reading and basing some
ideas on. Java socket ojects us byte-based buffers, not unicode. My
bad!
Regardless of the rest, I think the latter would be a large step backwards.
Clear distinction between bytes and unicode is a *feature* of Python 3.
Unicode-ignorant programmers should use frameworks which do the encoding work
for them.
+0.5
I'm beginning to agree; with the advent of b'' syntax in 2.6, the only
compelling reason to include this "feature" (examples that work without
modification across major versions of Python) goes up in smoke. The
examples should use the b'' syntax and have done with it.
(by the way, why you are targeting both Python 2 and 3?)
For the same reason that Python 3 features are introduced to 2.x;
migration. Users are more likely to adopt something that doesn't
require them to change production environments, and 3.x is far away
from being deployed in production anywhere but on Gentoo, it seems. ;)
Broad development and deployment options are a Good Thing™, and with
b'', there is no reason -not- to target 2.6+. (There is no requirement
that a PEP 444 / WSGI 2 server even try to be a cross-compatible
polygot; there is room for 2.x-specific and 3.x-specific solutions,
and, in theory, it should be possible to support Python < 2.6, I just
don't feel it's worthwhile to lock your application into Very Old™
interpreters.)
agronholm: I'm not very comfortable with the idea of wsgi.input in
async apps \ I'm just thinking what would happen when you do
environ['wsgi.input'].read()
GothAlice: One of two things: in a sync environment, it blocks until it
can read, in an async environment [combined with yield] it
pauses/shelves your application until the data is available.
Er, for the record, in Python 3 non-blocking file objects return None when
read() would block.
-1
I'm aware, however that's not practically useful. How would you detect
from within the WSGI 2 application that the file object has become
readable? Implement your own async reactor / select / epoll loop?
That's crazy talk! ;)
agronholm: the requirements of async apps are a big problem
agronholm: returning magic values from the app sounds like a bad idea
agronholm: the best solution I can come up with is to have
wsgi.async_input or something, which returns an async token for any
given read operation
The idiomatic abstraction for non-blockingness under POSIX is file descriptors.
So, at the low level (the WSGI level), exchanging fds between server and app
could be enough to allow both to wake up each other (perhaps two fds: one the
server can wait on, one the app can wait on). Similarly to what
signalfd() does.
Then higher-level tools can wrap inside Futures or whatever else.
-0
Hmm; I'll have to mull that over. Initial thoughts: having a magic
yield value that combines a fd and operation (read/write) is too
magical.
However, this also means Windows compatibility becomes more complicated, unless
the fds are sockets.
+1 for pure futures which (in theory) eliminate the need for dedicated
async versions of absolutely everything at the possible cost of
slightly higher overhead.
- Alice.
_______________________________________________
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
