On Tue, Feb 22, 2011 at 6:41 AM, Chris Beaven <[email protected]> wrote: > After hunting down a very elusive bug, I found the cause to be due to the > fact that render_to_string leaves the context in a different state than it > started (due to the context stack being pushed before rendering, and then > not popped). > This behavior differs from a standard Template.render call and it seemed > like a straight forward enough inconsistency so I committed [1] which > changed render_to_string to leave the context how it found it. > Being an idiot, I did my full test-suite pass against the wrong branch and > therefore failed to heed some warning bells of the impact of this :( > I've since fixed the test-suite failures [2] (there's still one outstanding > issue [3] although that has an easy enough solution). > > Anyway, the change in [1] is backwards incompatible, due to the fact that > people may be relying on the render_to_string (or render_to_response which > uses this method) method leaving the context stack 'unresolved'.
Bugs have never been considered as part of our backwards compatibility policy. To me, this falls clearly in the category of "bug". I can't think of any reason why render_to_string() would be expected to be context modifying. So, Option B (keep the change but document it in release notes) seems right to me. On a related note -- I noticed that our "bugs aren't covered" angle isn't actually mentioned as an exception to API stability. That should probably be rectified. Yours, Russ Magee %-) -- 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.
