On Wed, 2010-11-10 at 13:04 +0100, Will Hardy wrote: > > Reading over the discussion, I'm in the same camp as Luke. I can see > > the use case, but I see a bunch of sharp edges that will end up biting > > the user in unexpected ways. > > Thanks for dropping by :-) I think I've managed to remove the sharp edges.
The proposed solution isn't compelling IMO. Specifying a set of filters as a whitelist (or as a blacklist) is a very brittle mechanism. First, you depend only on the name of the function - so one that shadows a builtin filter won't be treated correctly (as you noted on the ticket). Second, when you are defining an autoescape function you have to know all the filters it will ever be used with. This is just as ugly a constraint as the problem it is trying to fix. Third, although we can fix the filters in your 'group 2', you can't fix 3rd party filters like this. If we don't fix them, we still have caveats that we have to add to the docs - "Be aware that any filters/tag not bundled with Django may be broken with respect to autoescape" etc. Overall, with this addition, the whole thing actually gets harder to understand and document, and just feels like a hack. That kind of thing is acceptable to fix existing bugs, but not for new features IMO. Luke -- I never hated a man enough to give him his diamonds back. (Zsa Zsa Gabor) Luke Plant || http://lukeplant.me.uk/ -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-develop...@googlegroups.com. To unsubscribe from this group, send email to django-developers+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/django-developers?hl=en.
