Simple, Elegant, and Powerful:

A generator expression in conjuction with a builtin… (python 2.5+)

any(x for x in mylist if x.n == 10)

Uses the Python any() builtin, which is defined as follows:

any(iterable) -> Return True if any element of the iterable is true. Equivalent to:

def any(iterable):
    for element in iterable:
        if element:
            return True
    return False

In the case of object filtering where you want to do an inclusive union of a subset of properties to equal a limited set of values and then perform any option (including list the attribute values) of the filtered list you can do the following using generators in a single statement (last line of code, the rest is there for instruction showing generating a large list of objects using matrix multiplication to generate constructor params)

#!/usr/bin/env python
import itertools
import pprint
class myObj(object):
    attr_1 = None
    attr_2 = None
    attr_3 = None
    def __init__(self, at1, at2, at3):
        self.attr_1 = at1
        self.attr_2 = at2
        self.attr_3 = at3
        super(myObj, self).__init__()

    def __repr__(self):
        return '<%s %s>' % (type(self), pprint.pformat(self.__dict__))

objs = itertools.starmap(myObj, itertools.product(iter('val_%d' % (i) for i in
    range(1,4)), repeat=3))

filter_dict = {
    'attr_1' : 'val_1',
    'attr_2' : 'val_2',
    'attr_3' : 'val_3',
}
print(list(result.attr_3 for result in objs if not list(False for pn,cval in
    filter_dict.items() if getattr(result, pn, None) != cval)))

Since you are writing Django code, you don't need lambdas at all (explanation below). In other Python code, you might want to use list comprehensions, as other commenters have mentioned. lambdas are a powerful concept, but they are extremely crippled in Python, so you are better off with loops and comprehensions.

Now to the Django corrections.

tasks = Task.objects.all()

tasks is a QuerySet. QuerySets are lazy-evaluated, i.e. the actual SQL to the database is deferred to the latest possible time. Since you are using lambdas, you actually force Django to do an expensive SELECT * FROM ... and filter everything manually and in-memory, instead of letting the database do its work.

contexts_to_display = ...

If those contexts are Django model instances, then you can be more efficient with the queries and fields instead of separate methods:

# tasks = Task.objects.all()
# tasks = filter(lambda t: t.matches_contexts(contexts_to_display), tasks)    
# tasks = filter(lambda t: not t.is_future(), tasks)
# tasks = sorted(tasks, Task.compare_by_due_date)
qs = Task.objects.filter(contexts__in=contexts_to_display, date__gt=datetime.date.today()).order_by(due_date)
tasks = list(qs)

The last line will cause Django to actually evaluate the QuerySet and thus send the SQL to the database. Therefore you might as well want to return qs instead of tasks and iterate over it in your template.

You can that using reduce from functools.

Let's start by creating the sample data:

class MyObject:
    def __init__(self, id: int, result_name: str):
        self.id = id
        self.result = Result(result_name)


class Result:
    def __init__(self, name: str):
        self.name = name

object1 = MyObject(1, 'A')
object2 = MyObject(2, 'A')
object3 = MyObject(3, 'B')
object4 = MyObject(4, 'B')

x_ids = (object1, object2, object3, object4)

Now we perform the list comprehension:

from functools import reduce
result = tuple(reduce(lambda t, s: {**t, s.result.name: s}, x_ids, {}).values())

Result:

(object2, object4)

The list comprehension (reduce) starts with an empty dict {}. Each iteration, an entry from x_ids is passed to the lambda function as s and the current state of the dict is passed as t. The dict gets updated by adding the object s with key s.result.name. If that key already exists, the entry will be overwritten - this filters out objects with the same result name. The result is a dict: {'A':object2, 'B':object4}. The result is then converted into the required tuple format.

This is a somewhat religious issue in Python. Even though Guido considered removing map, filter and reduce from Python 3, there was enough of a backlash that in the end only reduce was moved from built-ins to functools.reduce.

Personally I find list comprehensions easier to read. It is more explicit what is happening from the expression [i for i in list if i.attribute == value] as all the behaviour is on the surface not inside the filter function.

I would not worry too much about the performance difference between the two approaches as it is marginal. I would really only optimise this if it proved to be the bottleneck in your application which is unlikely.

Also since the BDFL wanted filter gone from the language then surely that automatically makes list comprehensions more Pythonic ;-)