Account Options

  1. Sign in
The old Google Groups will be going away soon, but your browser is incompatible with the new version.
Google Groups Home
« Groups Home
Python: Web SIG
Home
+ new post
About this group
Join this group
Message from discussion PEP 444 / WSGI 2 Async
The group you are posting to is a Usenet group. Messages posted to this group will make your email address visible to anyone on the Internet.
Your reply message has not been sent.
Your post was successful
 
From:
To:
Cc:
Followup To:
Add Cc | Add Followup-to | Edit Subject
Subject:
Validation:
For verification purposes please type the characters you see in the picture below or the numbers you hear by clicking the accessibility icon. Listen and type the numbers you hear
 
Alice Bevan–McGregor  
View profile  
 More options Jan 6 2011, 10:27 am
From: Alice Bevan–McGregor <al...@gothcandy.com>
Date: Thu, 6 Jan 2011 07:27:50 -0800
Local: Thurs, Jan 6 2011 10:27 am
Subject: Re: [Web-SIG] PEP 444 / WSGI 2 Async
Print | View thread | Show original | Report this message | Find messages by this author
On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:

> Alice Bevan-€“McGregor <alice@...> 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-...@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe: http://mail.python.org/mailman/options/web-sig/python-web-sig-garchiv...


 
You must Sign in before you can post messages.
To post a message you must first join this group.
Please update your nickname on the subscription settings page before posting.
You do not have the permission required to post.
Create a group - Google Groups - Google Home - Terms of Service - Privacy Policy
©2013 Google