#3192: [patch] Noisier bugs in context processors
-----------------------------------------------+----------------------------
Reporter: Jeremy Dunck <[EMAIL PROTECTED]> | Owner: nobody
Status: reopened | Component:
Template system
Version: SVN | Resolution:
Keywords: | Stage: Design
decision needed
Has_patch: 1 | Needs_docs: 0
Needs_tests: 0 | Needs_better_patch: 1
-----------------------------------------------+----------------------------
Changes (by jdunck):
* status: closed => reopened
* resolution: invalid =>
Old description:
> I just spent an embarrassingly long time figuring out the cause of
> "'NoneType' object has no attribute 'has_key'" when rendering a template.
>
> I had a buggy context processor which returned None under some
> conditions, which then made it onto the context stack.
>
> It seems to me that Context.update could verify that it's getting an
> object that supports __getitem__ since it counts on that (and give a
> helpful error if it's not the case), but I understand context needs to be
> high-performance, and generally update is called for context processors
> anyway.
>
> Perhaps RequestContext.__init__ could raise a TypeError.
>
> Patch attached. Feel free to ignore if I'm the only one to be bitten by
> this. :-/
New description:
I just spent an embarrassingly long time figuring out the cause of
"'NoneType' object has no attribute 'has_key'" when rendering a template.
I had a buggy context processor which returned None under some conditions,
which then made it onto the context stack.
It seems to me that Context.update could verify that it's getting an
object that supports __getitem__ since it counts on that (and give a
helpful error if it's not the case), but I understand context needs to be
high-performance, and generally update is called for context processors
anyway.
Perhaps RequestContext.__init__ could raise a TypeError.
Patch attached. Feel free to ignore if I'm the only one to be bitten by
this. :-/
Comment:
Re-opening for clarification. I'm not fighting the invalid decision, if
my point is understood, but ubernostrum suggested that maybe it wasn't.
I agree that a context processor *must* return a dictionary. What I'm
trying to address, here, is that it isn't immediately obvious when a bug
exists in a context processor which causes it not to return the expected
type.
If a context processor returns an object which can't be used as a
dictionary, an error does not occur until much later, and then that error
1) kills template rendering rather than using TEMPLATE_STRING_IF_INVALID,
and 2) doesn't hint that a context processor may have caused the problem.
...And I'm using hasattr...'__getitem__' rather than isinstance(..., dict)
because Context itself doesn't inherit from dict, and smashing contexts
together currently works, so I didn't want the change to start insisting
on a dictionary.
Finally, I'm not using "try...except" because Context.update doesn't throw
an exception when handed something other than a dictionary-- it happily
appends None to the stack of *expected* dictionaries to be checked upon
context lookup, i.e. Context.__getitem__.
Feel free to close as invalid before, but I hope I've made my rationale
clearer.
--
Ticket URL: <http://code.djangoproject.com/ticket/3192#comment:4>
Django Code <http://code.djangoproject.com/>
The web framework for perfectionists with deadlines
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups
"Django updates" 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-updates?hl=en
-~----------~----~----~----~------~----~------~--~---
