On Friday 04 July 2008 13:14, Iwan wrote: > 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 -- python has no ordering in its > > namespaces/scopes/frames (a plain dict). > > But what if you assume: > - the "context" is a dict (so you can modify it as you wish to add > things) > - that there is only one per call stack > > I think that is all which is needed for what I'd want to do? well... practicaly, it is. until proven wrong some day -- it's up to you to decide.
> > There's another approach, organise yourself a stack and use that one, > > be it threadlocal or global or what. > > Not sure that I follow what you're suggesting. I could, instead of > holding on to a singleton dict, rather have a stack of them - so each > time I add stuff to it, I push the new stuff on top - like a proper > scoping mechanism. Is that what you mean? the idea is to have a stack / stacks under your control, paralel to the appllication stack. what u hold onto each level is whatever your context is - DBhandle, UIhandle, timecontext,user-identification... Thus u organise the scoping the way u want - logical level scopes does not have to be same granularity as programming level scopes - or even follow them - logical stack can be workflow-driven and not by code-structure. u can have multiple stacks with different scoping rules for the different aspects. The programming scoping can still be used for easy push/pop your stack, but that is not anymore the only way.. > > i have some working example at > > dbcook/misc/timed/util/stacks.py:http://dbcook.svn.sourceforge.net/viewvc > >/dbcook/trunk/dbcook/misc/tim... and a maybe-working usage in > > dbcook/misc/timed/ timecontext.py + setup.py > > have a look > > I did, but can't really follow - can't read your comments? i translated stacks.py comments, see again. the rest - the only partialy-relevant comments there is in setup.py - saying that the _default thing is a singleton than holds the initial stack, all else hooks to it (but thats just one scheme of usage.) all else is timecontext/bitemporal stuff. ciao svilen --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to sqlalchemy@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
