On Sun, Nov 9, 2008 at 3:48 AM, James Bennett <[EMAIL PROTECTED]> wrote: > > On Sat, Nov 8, 2008 at 5:34 PM, Russell Keith-Magee > <[EMAIL PROTECTED]> wrote: >> However, to clarify - are you talking about a backwards incompatible >> change, or are you talking about putting a backwards compatible layer >> in place that tries to tell the difference between the two modes of >> access? > > I'd prefer backwards compatibility. The way I'm envisioning it would > complicate the code a bit, but I think preserving compatibility is > worth it: > > 1. response.context simply stuffs away a complete copy of the final > Context used in rendering, as well as the current behavior of > maintaining a list of contexts. > 2. A call to response.context.__getitem__() with a string argument > goes straight into that Context; thanks to Context's own fall-through > semantics, this will find a key (if it's there to be found) in > whatever layer of the context stack it happens to be in. > 3. A call to response.context.__getitem__() with an integer argument > 'n' returns Context 'n' out of the list.
does this mechanism work with contexts with integer-keys? gabor --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
