On Jul 4, 3:41 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 4, 2008, at 5:40 AM, Iwan wrote:
Assume also that CC.get_context_hash() returns id(CC.get_context())
Session = scoped_session(sessionmaker(),
scopefunc=CC.get_context_hash)
if get_context_hash returns a dict, thats
On Jul 6, 2008, at 5:08 AM, Iwan wrote:
On Jul 4, 3:41 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 4, 2008, at 5:40 AM, Iwan wrote:
Assume also that CC.get_context_hash() returns id(CC.get_context())
Session = scoped_session(sessionmaker(),
scopefunc=CC.get_context_hash)
if
svilen,
On Jul 3, 5:58 pm, [EMAIL PROTECTED] wrote:
it is possible to dig the stack to find the context u need... no
worries about that, but u have to know the name of it, as there might
be two contexts living in same scope (e.g.: copy data from DB1 to
DB2), and u could get the wrong one --
Michael
On Jul 3, 3:58 pm, Michael Bayer [EMAIL PROTECTED] wrote:
On Jul 3, 2008, at 5:05 AM, Iwan wrote:
I was wondering if it is not possible to do something that is local to
the current call-stack, instead of the current thread.
[SNIP]
the currentframe usage is something I'd leave to
On Jul 3, 2008, at 5:05 AM, Iwan wrote:
I was wondering if it is not possible to do something that is local to
the current call-stack, instead of the current thread. I think there
are two issues here:
a) a general mechanism for remembering a call-local context
b) using it to provide a
it is possible to dig the stack to find the context u need... no
worries about that, but u have to know the name of it, as there might
be two contexts living in same scope (e.g.: copy data from DB1 to
DB2), and u could get the wrong one -- python has no ordering in its
