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. This maintains backward compatibility for people doing things like "response.context[0]['foo']", and maybe we can toss in a DeprecationWarning and eventually get rid of that behavior, but more importantly it makes "response.context['foo']" always work. -- "Bureaucrat Conrad, you are technically correct -- the best kind of correct." --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
