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 tha
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?
On Jul 8, 2008, at 2:31 PM, Phillip J. Eby wrote:
At 11:35 AM 7/8/2008 -0700, Donovan Preston 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 se
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 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 t
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 ex
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 in
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 mo
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
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 i
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 th
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 wsgi
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
related
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 th
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
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 desi
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
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,
On Mon, 2008-07-07 at 13:48 +0100, Matt Goodall wrote:
> Iwan Vosloo 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 archite
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 dur
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
p
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.
> >>
> >> Wha
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 we
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
> asynchr
Iwan Vosloo wrote:
> 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 contex
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 of
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
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
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 so
Hi Martijn,
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 to uniquely identify "context", scoped_session
> could also be
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
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 assu
32 matches
Mail list logo