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 th
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256
On 2016-04-19 08:03:39 +, Marcel Hellkamp said:
Currently, all the links in this mail are dead.
That's curious, they weren't 11 hours ago, and analytics shows activity.
Weird. Looks like only the first two links were affected by subtle ID
ch
Best Practices Morpheus says: "What if I told you things can get
simpler, more independent, and more testable, with a separation of
concerns in a glorious holy land?"
WebCore is a WSGI nanoframework, a fraction of the size of competing
“microframeworks”, and culmination of more than ten years
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 pushin
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
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-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 m
On 2011-04-15 11:02:17 -0700, Jim Fulton said:
On Fri, Apr 15, 2011 at 1:32 PM, Éric Araujo
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, command hooks and
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 featur
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
wrote:
3. Define how to get the WSGI app. This is WSGI specific, but (1) is
*not* WSGI specific (it's only Python specific,
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
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 assumin
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 list
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
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. A
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: h
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 d
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" fo
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 idea
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 implem
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 imple
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 substant
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 t
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 d
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 thei
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 co
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, t
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 07:04:49 -0800,
exar...@twistedmatrix.com said:
Don't say it if it's not true. Deferreds aren't tied to a reactor, and
Marrow doesn't appear to have anything called "deferred". So this
parallel to Twisted's Deferred is misleading and confusing.
It was merely a comparison to t
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 thi
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 mea
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
async>>servers will /already/ be implementing their own executors, I
don't>>see this as
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 w
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 how
On 2011-01-08 09:00:18 -0800, P.J. Eby said:
(The next interesting challenge would be to integrate this withGraham's
proposal for adding cleanup handlers...)
class MyApplication(object):
def __init__(self):
pass # process startup code
def __call__(self, environ):
yield Non
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
hel
o
https://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–
On 2011-01-08 06:49:13 -0800, David Stanek said:
Is there a list somewhere of the warts that need to be fixed? I found
some in this list's archive and on various blogs, but I was hoping to
find a more comprehensive grouping of them.
Graham Dumpleton, the author of Apache's mod_wsgi, has blogg
On 2011-01-08 06:08:57 -0800, David Stanek said:
Under the new spec would I be forced to make my applications and
middleware this complicated?
An application that does not utilize futures (and thus this proposal
for async) is different from the current draft as it is written [1] by
only one w
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 th
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 to
On 2011-01-07 16:39:46 -0800, Alex Grönholm said:
I believe allowing wsgi.executor to be either a process pool or a
thread pool is a recipe for disaster. I'm really not sure where to go
from here.
Two solutions:
:: Don't pass an executor to the job such that it can not schedule its
own futur
mpatibility via 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 writes:
The particular use case happens to be PEP 444 as implemented using an
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
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. (O
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 t
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 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. (Wh
On 2011-01-07 08:28:15 -0800, P.J. Eby said:
At 01:17 AM 1/7/2011 -0800, Alice BevanMcGregor wrote:
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by>>>incorporating>the
most common (1%) of features most often>>>relegated to middleware>or
functio
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
the>load across cores). Also, only one sacle is immediately
required>before returning the post-upload page: the thumbnail. The
o
On 2011-01-07 09:04:07 -0800, Antoine Pitrou said:
Alice Bevan–McGregor 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
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 applic
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 lik
On 2011-01-06 20:18:12 -0800, P.J. Eby said:
:: Reduction of re-implementation / NIH syndrome by incorporating>the
most common (1%) of features most often relegated to middleware>or
functional helpers.
Note that nearly every application-friendly feature you add will
increase the burden on bot
On 2011-01-06 10:15:19 -0800, Antoine Pitrou said:
Alice Bevan–McGregor 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 applic
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 describ
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 adoptio
On 2011-01-06 21:35:24 -0800, Jacob Kaplan-Moss said:
And I'm feeling incredibly disheartened.
As the author of my own small WSGI framework (with world-wide, though
still limited use) I have the luxury of being able to embrace
experimental technologies. The lack of WSGI capability in Python
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 cases
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 HT
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 09:20:48 -0800, Randy Syring said:
Being a web application developer and relying on frameworks like
Werkzeug and WebOb, I may not have much of a dog in this fight.
All input is welcome; I do want to hear from both framework developers
and users of frameworks. I suspect this disc
On 2011-01-06 14:01:09 -0800, James Y Knight said:
No you don't -- HTTP 1.0 allows indeterminate-length output. The server
simply must close the connection to indicate the end of the response if
either the client version HTTP/1.0, or the server doesn't implement
HTTP/1.1.
Ah, you are correct
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 me
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
It seems to me that the spec that Alice is working on could be
something great but the problems are not well defined (in the PEP).
This causes confusion about what the goals are.
For completeness sake, here's a slightly simplified Abstract:
:: A proposed second-generation standard interface b
ke 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
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) w
On 2011-01-06 03:53:14 -0800, Antoine Pitrou said:
Alice Bevan-McGregor 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; a
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, p
[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 au
On 2011-01-02 11:57:19 -0800, P.J. Eby said:
FWIW, my lack of interest has been due to two factors. First,
theoriginal version of PEP 444 before you worked on it was questionable
in my book, due to the addition of new optional features (e.g. async),
and second, when I saw your "filters" propos
On 2011-01-02 13:31:45 -0800, Guido van Rossum said:
Masklinn, those are pretty strong words (bordering on offensive). I'm
sure Alice has a different opinion. Alice, hopefully you can write down
your ideas for all to see? Perhaps you have an implementation too?
Maybe seeing a concrete proposal
On 2011-01-02 11:14:00 -0800, Chris McDonough said:
I'd suggest we just embrace it, adding minor tweaks as necessary, until
we reach some sort of technical impasse it doesn't address.
Async is one area that does not cover, and that by not having a
standard which incorporates async means c
On 2011-01-02 09:21:29 -0800, Guido van Rossum said:
Alice hasn't posted a link to her rewrite of PEP 444 in a while. AFAICT
it's this:
https://github.com/GothAlice/wsgi2/blob/master/pep444.textile . I find
it a bit disturbing that the "official" copy of PEP 444
(http://www.python.org/dev/peps
"After some discussion on the Web-SIG mailing list, PEP 444 is now
"officially" WSGI 2, and PEP is WSGI 1.1"
This out-of-context quote came after prior discussion of PEP 444 (and
clear statements of draft-ness) throughout a rather excellent thread on
HTTP server performance.
The majorit
Graham,
GothAlice (don't know off hand there real name), keeps going around and
claiming:
Alice Zoë Bevan-McGregor. If the unicode in my newsreader doesn't
work, that's an e with an umlaut.
I have pointed out a couple of times to them that there is no way that
PEP 444 has been blessed as
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 inter
Ian,
It's not clear to me how this can be composed or abstracted.
Filters themselves have no knowledge of the applicaiton, in a similar
vein to middleware not knowing if the next layer in the onion skin is
the final application, or another bit of well-behaved middleware,
except that filters
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 fi
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 s
The updated text is available at:
https://github.com/GothAlice/wsgi2/blob/master/pep-0444.rst
Forgot to mention that in the last message.
— Alice.___
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscrib
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 s
On 2010-11-22, at 3:05 PM, Mark Ramm 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 traffic, is a registered t
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, Chri
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 possible
> 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
(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 of
88 matches
Mail list logo