Hi Julien, On 06/17/2011 12:08 PM, Julien Phalip wrote: > Just noting that another "filtering" functionality has recently been > added to trunk [1]. It is a different kind of filtering than what's > being discussed here -- it is to filter out sensitive information from > error reports when they're being produced. Maybe the naming of one of > those functionalities might need to be reconsidered in order to avoid > confusion in the docs and APIs. I'm not sure. Just thought I'd point > it out ;)
Since "filters" are already a built-in feature of the logging package in Python's standard library, and we're just making use of that existing feature, we don't have the option of changing naming here: i.e., the keys in LOGGING must be named "filters" or they just won't work with logging.dictConfig. (Even if we could do it, it'd be a mistake to try to impose alternate Django terminology on a feature of a Python standard library component). In any case, we already have plenty of uses of "filter" in Django: there's the ORM .filter() method, and ModelAdmin.list_filter, just off the top of my head. I don't think there's a problem here: "filter" is a generic term, and if there's any potential for confusion it must be qualified. "Error filtering" vs "logging filters" vs "admin changelist filters", etc. > (By the way, "production" is a common generic term used for when DEBUG > is False) True that it's used for that, but it doesn't exclusively mean that; therefore I think DebugFalseFilter is a clearer name than ProductionFilter. I would have to look at docs or implementation to be confident I knew what the latter did; not so for the former. Carl -- You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@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.
