_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.

[Russell Keith-Magee]

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.

[Alexander Koshelev]

Better path with tests for current trunk

[Chris Beaven]

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

[Matthias Kestenholz]

Patch does not apply anymore.

[Chris Beaven]

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

[Chris Beaven]

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

[Tai Lee]

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

[Luke Plant]

(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