Donovan Preston ha scritto:
[...]
It seems to me that what is really needed here is an extension of wsgi
that specifies how to get, set, and list request local storage, and for
people to use that instead of the threadlocal module.
There seems to be something that I don't understand: why not
On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of
wsgi
that specifies how to get, set, and list request local storage, and
for people to use that instead of the threadlocal
Donovan Preston ha scritto:
On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of wsgi
that specifies how to get, set, and list request local storage, and
for people to use that
On Jul 8, 2008, at 11:45 AM, Manlio Perillo wrote:
Using greenlets, there is always a current greenlet, so you can use
this for local storage.
A library function can check if there is an active greenlet, and use
it as data key; otherwise it will use the current thread id.
Yes, this is
Donovan Preston ha scritto:
On Jul 8, 2008, at 11:45 AM, Manlio Perillo wrote:
Using greenlets, there is always a current greenlet, so you can use
this for local storage.
A library function can check if there is an active greenlet, and use
it as data key; otherwise it will use the current
At 11:35 AM 7/8/2008 -0700, Donovan Preston wrote:
On Jul 7, 2008, at 6:11 PM, Phillip J. Eby wrote:
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of
wsgi
that specifies how to get, set, and list request local storage, and
for
Donovan Preston wrote:
On Jul 8, 2008, at 2:31 PM, Phillip J. Eby wrote:
Er, and how do you propose people *access* that interface rather
than a specific implementation of it? Wouldn't we need to pass it
in the environ, thereby rendering the whole thing even more
obviously moot? :)
Phillip J. Eby wrote:
Obviously plenty of
people have a desire to have a place to store request-local data
without passing the environment everywhere. Using threading.local is a
good way to do that, unless the server is not using one thread per
request. Giving people an interface to write to
Iwan Vosloo wrote:
On Fri, 2008-07-04 at 13:39 +0100, Matt Goodall wrote:
Iwan Vosloo wrote:
You're correct that Twisted Web does not allocate a thread per request.
All requests are handled by an event loop in the main thread.
In Twisted, the call stack tends to gets fragmented during a
Matt Goodall ha scritto:
[...]
True, but even passing a request or env dict around to everyone gets
tedious don't you think?
Yes, it can be tedious but I believe explicit arg passing is necessary
to make code readable, testable and reusable.
If it's web-related code then give it the request,
Ian Bicking ha scritto:
Manlio Perillo wrote:
I'm adding web-sig in Cc.
[...]
I'm developing a WSGI framework with all these (and other) ideas:
http://hg.mperillo.ath.cx/wsgix
Its still not documented, so I have not yet made an official
announcement.
The main design goal is to keep the
Manlio Perillo wrote:
Ian Bicking ha scritto:
Manlio Perillo wrote:
I'm adding web-sig in Cc.
[...]
I'm developing a WSGI framework with all these (and other) ideas:
http://hg.mperillo.ath.cx/wsgix
Its still not documented, so I have not yet made an official
announcement.
The main
Matt Goodall wrote:
Yes, it can be tedious but I believe explicit arg passing
is necessary to make code readable, testable and reusable.
...
I've made the mistake of relying on magic contexts in the
past. I'm still trying to fix things.
Can you elaborate?
Robert Brewer
[EMAIL PROTECTED]
Ian Bicking ha scritto:
Manlio Perillo wrote:
[...]
As an example, in Paste you have choosed to using config dictionary
for middleware configuration, that is, you have middleware factories.
I think this is a red herring. WebOb specifically doesn't do anything
related to configuration or
Manlio Perillo wrote:
Ian Bicking ha scritto:
Manlio Perillo wrote:
[...]
As an example, in Paste you have choosed to using config dictionary
for middleware configuration, that is, you have middleware factories.
I think this is a red herring. WebOb specifically doesn't do anything
Donovan Preston wrote:
To throw another wrench in things, with the Paste/WebError
evalexception interactive exception handler, it restores this
thread-local context so you can later execute expressions in the same
context.
It seems to me that what is really needed here is an extension of
On Jul 4, 2008, at 12:10 PM, Ian Bicking wrote:
Iwan Vosloo wrote:
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt
with.
Passing it all via parameters to every nook of your code is
cumbersome.
A lot of
At 02:12 PM 7/7/2008 -0700, Donovan Preston wrote:
It seems to me that what is really needed here is an extension of wsgi
that specifies how to get, set, and list request local storage, and
for people to use that instead of the threadlocal module.
I don't follow why you wouldn't just put that
Hi,
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook of your code is cumbersome.
A lot of the frameworks use a thread local context to solve this
problem. I'm
Hi there,
2008/7/4 Iwan Vosloo [EMAIL PROTECTED]:
[snip]
A lot of the frameworks use a thread local context to solve this
problem. I'm assuming these are based on threading.local.
(See, for example:
http://www.sqlalchemy.org/docs/05/session.html#unitofwork_contextual )
scoped_session is
Iwan Vosloo ha scritto:
Hi,
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook of your code is cumbersome.
A lot of the frameworks use a thread local context to
On Fri, 2008-07-04 at 13:42 +0200, Manlio Perillo wrote:
Iwan Vosloo ha scritto:
Hi,
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook of your code is
Hey,
On Fri, Jul 4, 2008 at 1:37 PM, Iwan Vosloo [EMAIL PROTECTED] wrote:
On Fri, 2008-07-04 at 13:31 +0200, Martijn Faassen wrote:
scoped_session is actually, I think, a bad example, as SQLAlchemy uses
the thread id to scope things per session, not threading.local. As
long as there's a way
Iwan Vosloo ha scritto:
On Fri, 2008-07-04 at 13:42 +0200, Manlio Perillo wrote:
Iwan Vosloo ha scritto:
Hi,
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook
On Fri, 2008-07-04 at 13:39 +0100, Matt Goodall wrote:
Iwan Vosloo wrote:
You're correct that Twisted Web does not allocate a thread per request.
All requests are handled by an event loop in the main thread.
In Twisted, the call stack tends to gets fragmented during a sequence of
On Fri, Jul 4, 2008 at 9:23 AM, Iwan Vosloo [EMAIL PROTECTED] wrote:
On Fri, 2008-07-04 at 13:39 +0100, Matt Goodall wrote:
The ideal solution is, of course, to pass everything around to whatever
needs it. However, there's really tedious at times.
Whatever the architecture of the web server
Benji York wrote:
On Fri, Jul 4, 2008 at 9:23 AM, Iwan Vosloo [EMAIL PROTECTED] wrote:
On Fri, 2008-07-04 at 13:39 +0100, Matt Goodall wrote:
The ideal solution is, of course, to pass everything around to
whatever
needs it. However, there's really tedious at times.
Whatever the
Iwan Vosloo wrote:
Many web frameworks and ORM tools have the need to propagate data
depending on some or other context within which a request is dealt with.
Passing it all via parameters to every nook of your code is cumbersome.
A lot of the frameworks use a thread local context to solve this
28 matches
Mail list logo
