_resolve_lookup could do a better job of resolving callables and correctly catching silent_variable_failure exceptions

[Ionut Ciocirlan <ionut.ciocirlan@…>]

Right now callables are run only if they are object methods and dictionary lookup failed (which means a DictMixin-like method wouldn't get called).

I don't think this is meant by design, so this patch moves the callable check at the end of _resolve_lookup(), making all callables passed to the template get run.

[russellm]

Sounds like a reasonable proposition, but I'm not going to check in something like this without tests. Reminder to triagers - tests are not optional.

[alexkoshelev]

Better path with tests for current trunk

[SmileyChris]

another test, and also adding catching silent variable failures everywhere (with tests)

[mk]

Patch does not apply anymore.

[SmileyChris]

PS: you're doing a great job of triage, mk.

[SmileyChris]

(In [14992]) Fixed #7153 -- _resolve_lookup now does a better job of resolving callables and correctly catches all silent_variable_exceptions

[mrmachine]

See #15057 for a patch with improved docs that describe the new behaviour.

[lukeplant]

(In [15188]) Fixed #15057 - documented change in [14992]

Thanks to Tai Lee for the patch.

Refs #15025, #7153

[charlie leifer]

This causes issues in any variable where the context lookup is a class. Rather than the class being returned, a bare instance is (assuming it can be instantiated without parameters). Is this expected behavior?

Here's how I ran into the issue: I drop a couple models into the context and do things with them in the template, namely passing the models in as filter arguments. In django 1.2.X, the classes are passed along intact into the filter. In 1.3.X, a bare instance of the class is passed in to the filter instead.

[anonymous]

Near as I can tell the behavior you note is expected and documented as a 1.3 change: ​https://docs.djangoproject.com/en/1.3/releases/1.3/#callables-in-templates