(A version of this is is available at http://web-core.org/2.0/pep-0444/ — links
are links, code may be easier to read.)
PEP 444 is quite exciting to me. So much so that I’ve been spending a few days
writing a high-performance (C10K, 10Krsec) Py2.6+/3.1+ HTTP/1.1 server which
implements much
PEP 444 has no champion currently. Both Armin and I have basically left it
behind. It would be great if you wanted to be its champion.
Done.
As I already have a functional, performant HTTP server[1] and example filter[2]
(compression) utilizing a slightly modified version of PEP 444, and
Would you prefer to give me collaboration permissions on your repo, or should I
fork it?
This message was sent from a mobile device. Please excuse any terseness and
spelling or grammatical errors. If additional information is indicated it will
be sent from a desktop computer as soon as
I’ve forked it, now available at:
https://github.com/GothAlice/wsgi2
Re-naming it to wsgi2 will be my first order of business during the week,
altering your association the second. I’ll post change descriptions for
discussion as I go.
— Alice.
On 2010-11-22, at 12:12 AM,
On 2010-11-22, at 3:05 PM, Mark Ramm mark.mchristen...@gmail.com wrote:
I would very much prefer it if we could keep the current name or choose a new
unrelated name, not wsgi2 as I think there API changes warrant a new name to
prevent confusion.
Web3, as mentioned in previous mailing list
I’ve updated my copy of the PEP, re-naming non-commentary and non-revision text
to reference WSGI2, wsgi2, or wsgi (environment variables) as appropriate.
I’ve also added the first draft of the text describing filters and some sample
code, including a middleware adapter for filters. Here are
Howdy!
There's one issue I've seen repeated a lot in working with WSGI1 and
that is the use of middleware to process incoming data, but not
outgoing, and vice-versa; middleware which filters the output in some
way, but cares not about the input.
Wrapping middleware around an application is
That looks amazingly like the code for CherryPy Filters circa 2005. In
version 2 of CherryPy, Filters were the canonical extension method
(for the framework, not WSGI, but the same lessons apply). It was still
expensive in terms of stack allocation overhead, because you had to
call () each
Howdy!
I've mostly finished a draft rewrite of PEP 444 (WSGI 2), incorporating
some additional ideas covering things like py2k/py3k interoperability
and switching from a more narrative style to a substantially
RFC-inspired language.
http://bit.ly/e7rtI6
I'm using Textile as my
[Apologies if this is a double- or triple-post; I seem to be having a
stupid number of connectivity problems today.]
Howdy!
Apologies for the delay in responding, it’s been a hectic start to the
new year. :)
On 2011-01-03, at 6:22 AM, Timothy Farrell wrote:
You don't know me but I'm the
Alex Grönholm and I have been discussing async implementation details
(and other areas of PEP 444) for some time on IRC. Below is the
cleaned up log transcriptions with additional notes where needed.
Note: The logs are in mixed chronological order — discussion of one
topic is chronological,
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
Chris,
On 2011-01-06 05:03:15 -0800, Chris Dent said:
On Wed, 5 Jan 2011, Alice Bevan–McGregor wrote:
This should give a fairly comprehensive explanation of the rationale
behind some decisions in the rewrite; a version of these
conversations (in narrative style vs. discussion) will be added
an effort to trim quoted text to only the relevant parts.
On Thu, 6 Jan 2011, Alice Bevan–McGregor wrote:
https://github.com/GothAlice/wsgi2/blob/master/pep444.textile
Thanks, watching that now.
The textile document will no longer be updated; the pep-444.rst
document is where it'll
On 2011-01-06 13:06:36 -0800, James Y Knight said:
On Jan 6, 2011, at 3:52 PM, Alice Bevan–McGregor wrote:
:: Making optional (and thus rarely-implemented) features non-optional.
E.g. server support for HTTP/1.1 with clarifications for interfacing
applications to 1.1 servers. Thus pipelining
On 2011-01-06 13:08:04 -0800, Robert Brewer said:
Or, if you had actually read what I wrote weeks ago...
I did. Apologies for forgetting the detail of the implementation being
deprecated.
We don't need Yet Another Way of hooking in processing components; if
anything, we need a standard
On 2011-01-06 14:14:32 -0800, Alice Bevan–McGregor said:
There was something, somewhere I was reading related to WSGI about
requiring content-length... but no matter.
Right, I remember now: the HTTP 1.0 specification. (Honestly not
trying to sound sarcastic!) See:
http://www.w3
On 2011-01-06 21:26:32 -0800, James Y Knight said:
You've misread that section. In HTTP/1.0, *requests* were required to
have a Content-Length if they had a body (HTTP 1.1 fixed that with
chunked request support). Responses have never had that restriction:
they have always (even since before
On 2011-01-06 22:00:17 -0800, Graham Dumpleton said:
-environ = {k: wsgi_string(v) for k,v in os.environ.items()}
+environ = {k: wsgi_string(v) for k,v in list(os.environ.items())}
2to3 takes the conservative route of assuming your application treats
dict.items() as a list in all
On 2011-01-06 23:40:53 -0800, Graham Dumpleton said:
There is also uWSGI and CherryPy WSGI server. I recollect that Benoit
may have started looking it over for gunicorn.
Ah, right, I recall seeing CherryPy mentioned in archived discussions.
So there's hope, then, for relatively quick
On 2011-01-06 20:49:57 -0800, P.J. Eby said:
It would be helpful if you addressed the issue of scope, i.e.,
whatfeatures are you proposing to offer to the application developer.
Conformity, predictability, and portability. That's a lot of y's.
(Pardon the pun!)
Alex Grönholm's post
On 2011-01-06 10:15:19 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
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
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by incorporatingthe
most common (1%) of features most often relegated to middlewareor
functional helpers.
Note that nearly every application-friendly feature you add will
increase the burden on both
On 2011-01-07 01:08:42 -0800, chris.dent said:
... this particular goal [reduction of reimplementation / NIH] could
cover a large number of things from standardized query string
processing (maybe a good idea) to filters (which I've already expressed
reservations about).
So this goal seems
On Fri, Jan 7, 2011 at 9:47 AM, Timothy Farrell wrote:
There has been much discussion about how to handle async in PEP 444 and
that discussion centers around the use of futures. However, I'm
requesting that servers _optionally_ provide environ['wsgi.executor']
as a futures executor that
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
I don't understand why you want a yield at this level. IMHO, WSGI
needn't involve generators. A higher-level wrapper (framework,
middleware, whatever) can wrap fd-waiting in fancy generator stuff if
so
On 2011-01-07 08:10:43 -0800, P.J. Eby said:
At 12:39 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
:: Image scaling would benefit from multi-processing (spreading
theload across cores). Also, only one sacle is immediately
requiredbefore returning the post-upload page: the thumbnail. The
On 2011-01-07 12:42:24 -0800, Paul Davis said:
Is the code for this server online? I'd be interested in reading through it.
https://github.com/pulp/marrow.server.http
There are two branches: master will always refer to the version
published on Python.org, and draft refers to my rewrite.
On 2011-01-07 13:21:36 -0800, Antoine Pitrou said:
Ok, so, WSGI doesn't already involve generators. QED.
This can go around in circles; by allowing all forms of iterable, it
involves generators. Geneators are a type of iterable. QED right
back. ;)
Right, that's why I was suggesting you
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
WSGI doesn't mandate any specific feature of generators, such as
coroutine-like semantics, and the server doesn't have to know about
them.
The joy of writing a new specification is that we are not (potentially)
shackled by old ways of doing
On 2011-01-07 20:34:09 -0800, P.J. Eby said:
That it [handling generators] is difficult at all means removes
degree-of-difficulty as a strong motivation to switch.
Agreed. I will be following up with a more concrete idea (including
p-code) to better describe what is currently in my brain.
On 2011-01-07 22:13:17 -0800, Alex Grönholm said:
08.01.2011 07:09, P.J. Eby wrote:
On the plus side, the run this in a future after the request concept
has some legs... [snip]
What exactly does run this in a future after the request mean? There
seems to be some terminology confusion here.
the /already/ redefined return value)
I hope people do not reject this out of hand but instead help explore
the idea further.
On 2011-01-07 19:36:52 -0800, Antoine Pitrou said:
Alice Bevan–McGregor al...@... writes:
The particular use case happens to be PEP 444 as implemented using an
async
Warning: this assumes we're running on bizzaro-world PEP 444 that
mandates applications are generators. Please do not dismiss this idea
out of hand but give it a good look and maybe some feedback. ;)
--
Howdy!
I've finished touching up the p-code illustrating my idea of using
generators
As a quick note, this proposal would signifigantly benefit from the
simplified syntax offered by PEP 380 (Syntax for Delegating to a
Subgenerator) [1] and possibly PEP 3152 (Cofunctions) [2]. The former
simplifies delegation and exception passing, and the latter simplifies
the async side of
://github.com/pulp/marrow.server/tree/threaded
https://github.com/pulp/marrow.server.http/tree/threaded
This update has not been tested under Python 3.x yet; I'll do that
shortly and push any fixes; I doubt there will be any.
On 2011-01-08 03:26:28 -0800, Alice Bevan–McGregor said
On 2011-01-08 07:22:44 -0800, David Stanek said:
I'm going to take some time this weekend to create a consolidated list.
I was hoping to find something like:
Issue:
Discussion: http://
Summary of resolution: ...
I agree; that would be very, very nice to have, though it might be
On 2011-01-08 17:22:44 -0800, Alex Grönholm said:
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
I've written the sketches dealing only with PEP 3148 futures, but
sockets were also proposed, and IMO there should be simple support for
obtaining data from wsgi.input.
I'm a bit unclear as to
On 2011-01-08 20:06:19 -0800, Alex Grönholm said:
I liked the idea of having a separate async_read() method in
wsgi.input, which would set the underlying socket in nonblocking mode
and return a future. The event loop would watch the socket and read
data into a buffer and trigger the callback
On 2011-01-08 19:34:41 -0800, P.J. Eby said:
At 04:40 AM 1/9/2011 +0200, Alex Grönholm wrote:
09.01.2011 04:15, Alice BevanMcGregor kirjoitti:
I hope that clearly identifies my idea on the subject. Since
asyncservers will /already/ be implementing their own executors, I
don'tsee this as too
On 2011-01-08 13:16:52 -0800, P.J. Eby said:
In the limit case, it appears that any WSGI 1 server could provide an
(emulated) async WSGI2 implementation, simply by wrapping WSGI2 apps
with a finished version of the decorator in my sketch.
Or, since users could do it themselves, this would
Here's what I've mutated Alex Grönholm's minimal middleware example
into: (see the change history for the evolution of this)
https://gist.github.com/771398
A complete functional (as in function, not working ;) async-capable
middleware layer (that does nothing) is 12 lines. That, I
On 2011-01-09 07:04:49 -0800,
exar...@twistedmatrix.com said:
I think this effort would benefit from more thought on how exactly
accessing this external library support will work. If async wsgi is
limited to performing a single read asynchronously, then it hardly
seems compelling.
Apologies
On 2011-01-09 09:26:19 -0800, P.J. Eby said:
By the way, I don't really see the point of the new sketches you're doing...
I'm sorry.
...as they aren't nearly as general as the one I've already done, but
still have the same fundamental limitation: wsgi.input.
You missed the point entirely,
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
Hm. I'm not sure if I like that. The typical app developer really
shouldn't be yielding multiple body strings in the first place.
Wait; what? So you want the app developer to load a 40MB talkcast MP3
into memory before sending it? You want to
On 2011-01-09 17:06:28 -0800, Alice Bevan-McGregor said:
On 2011-01-09 09:03:38 -0800, P.J. Eby said:
The elephant in the room here is that while it's easy towrite these
example applications so they don't block, in practicepeople read files
and do database queries and what not in their requests
Howdy!
Here's a rewritten (and incomplete, but GET and HEAD requests work
fine) marrow.server.http branch [1] that illustrates a simple
application [2] and protocol implementation [3]. Most notably, examine
the 'resume' method [4].
The 'basic' example yields a future instance and uses the
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
Ok, now that we've had a week of back and forth about this, let me
repeat my threat. Unless more concerns are brought up in the next 24
hours, can PEP be accepted?
+9001 ( 9000)
It seems a lot of people are waiting for a decision
On 2011-01-10 04:25:40 -0800, Alice Bevan–McGregor said:
Note that this particular rewrite is not complete, nor has it been
profiled and optimized; initial benchmarks (using the 'benchmark'
example) show a reduction of ~600 RSecs from the 'draft' branch, which
is substantial, but hasn't been
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
Ok, now that we've had a week of back and forth about this, let me
repeat my threat. Unless more concerns are brought up in the next 24
hours, can PEP be accepted? It seems a lot of people are waiting
for a decision that enables
On 2011-01-10 13:12:57 -0800, Guido van Rossum said:
Ok, now that we've had a week of back and forth about this, let me
repeat my threat. Unless more concerns are brought up in the next 24
hours, can PEP be accepted? It seems a lot of people are waiting
for a decision that enables
On 2011-04-10 16:25:21 -0700, James Mills said:
+1 too. I would however like to see this idea developed in a generic
and useable way. ie: No zope/twisted deps or making it fit around
Django :)
Ideally it should be useable by the most basic (plain old WSGI).
The following are the collected
Howdy!
On 2011-04-10 19:06:52 -0700, Ian Bicking said:
There's a significant danger that you'll be creating a configuration
management tool at that point, not simply a web application description.
Unless you have the tooling to manage the applications, there's no
point having a standard for
On 2011-04-11 00:53:02 -0700, Eric Larson said:
Hi,
On Apr 10, 2011, at 10:29 PM, Alice Bevan–McGregor wrote:
However, the package format I describe in that gist does include the
source for the dependencies as snapshotted during bundling. If your
application is working in development, after
On 2011-04-11 13:49:20 -0700, Alex Grönholm said:
I use Ubuntu on all my servers, and linux single does not work with
it, I can tell you ;P
The number of poorly configured Ubuntu servers I have seen (and
replaced) is staggering. Any time the barrier to entry is lowered,
quality suffers:
Howdy!
On 2011-04-11 15:22:11 -0700, Ian Bicking said:
I... think we are misunderstanding each other or something.
Something. ;)
A nice tool that could use this format, for instance, would be a tool
that takes an app and creates a puppet recipe to setup a sever to host
the application.
pre-install-hooks: [
apt-get install libxml2, # the person deploying the package
assumes apt-get is available
run-some-shell-script.sh, # the shell script might do the following
on a list of URLs
wget http://mydomain.com/canonical/repo/dependency.tar.gz tar zxf
dependency.tar.gz rm
On 2011-04-11 16:13:06 -0700, Ian Bicking said:
(I'm confused; I just noticed there's a
web-sig@python.org and
python-web-...@googlegroups.com?)
I only see one actual gmane group, gmane.comp.python.web...
— Alice.
___
Web-SIG mailing
Eric,
Let me rephrase a few things.
On 2011-04-11 17:48:14 -0700, Eric Larson said:
pre-install-hooks: [
apt-get install libxml2, # the person deploying the package
assumes apt-get is available
Assumptions are evil. You could end up with multiple third-party
applications each assuming
On 2011-04-13 18:16:36 -0700, Ian Bicking said:
While initially reluctant to use zip files, after further discussion
and thought they seem fine to me, so long as any tool that takes a zip
file can also take a directory. The reverse might not be true -- for
instance, I'd like a way to install
Howdy!
I suspect you're thinking a little too low-level.
On 2011-04-14 00:53:09 -0700, Graham Dumpleton said:
On 14 April 2011 16:57, Alice Bevan–McGregor
al...@gothcandy.com wrote:
3. Define how to get the WSGI app. This is WSGI specific, but (1) is
*not* WSGI specific (it's only Python
On 2011-04-14 08:53:55 -0700, Randy Syring said:
Just wondering if Windows/IIS is being kept in mind as this discussion
is going on. I am having a hard time conceptualizing the things being
discussed, so can't really tell myself.
I'm trying pretty hard to ensure that non-compatible OS
On 2011-04-15 11:02:17 -0700, Jim Fulton said:
On Fri, Apr 15, 2011 at 1:32 PM, Éric Araujo
mer...@netwok.org wrote:
As an aside, I wonder why people use dot+colon notation instead of just
dots to reference callables. In distutils2 for example we resolve
dotted names to find command classes,
On 2011-04-14 10:34:59 -0700, Ian Bicking said:
I think there's a general concept we should have, which I'll call a
script -- but basically it's a script to run (__main__-style), a
callable to call (module:name), or a URL to fetch internally.
Agreed. The reference notation I mentioned in my
On 2011-04-18 14:11:21 -0700, Daniel Holth said:
The file format discussion seems utterly pointless.
That's a pity.
If you want the format to specify cron jobs and services and non-wsgi
servers, why not go the whole way and use the Linux filesystem
hierarchy standard. The entry point is an
On 2011-04-18 16:36:28 -0700, Daniel Holth said:
On Apr 18, 2011, at 6:09 PM, Alice Bevan–McGregor wrote:
I've already defined that. RTFM or many ML messages about logging.
Please remain friendly and patient.
That depends on how you define the F in RTFM. In this instance, I
meant read
On 2011-04-15 22:33:08 +, P.J. Eby said:
At 04:11 PM 4/15/2011 -0400, Fred Drake wrote:
These end users don't really care if the object identified is a class or
function in module, a nested attribute on a class, or anything else, so
long as it does what it's advertised to do. By not
On 2016-04-19 12:56:26 +, Ian Cordasco said:
* Annotated Source Documentation: http://s.webcore.io/fjVc
(pythonhosted docs, also linked on the pypi page)
For what it's worth, the PyPI/Warehouse/PyPA developers are planning
on deprecating pythonhosted for PyPI packages. The suggestion is
68 matches
Mail list logo
