refactor: update KlassDetailView by converting ancestors to set

[allrob23]

This PR enhances the KlassDetailView in cbv/views.py by making a small but effective change. The original code converted klass.get_ancestors() to a list:

-        direct_ancestors = list(klass.get_ancestors())
+        direct_ancestors = set(klass.get_ancestors())

I made this because in the next command we have a ancestor in direct_ancestors

       direct_ancestors = set(klass.get_ancestors())
        ancestors = [
            self.Ancestor(
                name=ancestor.name,
                url=ancestor.get_absolute_url(),
                is_direct=ancestor in direct_ancestors,
            )
            for ancestor in klass.get_all_ancestors()
        ]

Why This Change?

1. Performance: Converting to a set instead of a list improves lookup efficiency. Sets offer O(1) membership testing compared to O(n) for lists, which is beneficial when direct_ancestors is use in lookups.
2. No Logic Change: The core behavior remains identical—only the data structure is optimized. This ensures stability while boosting performance.

Though the performance gain might not be dramatic for small datasets, this change is a proactive step toward scalability and cleaner code

[ghickman]

@allrob23 – Thanks for taking the time to contribute!

While this PR is very small and looks like it should be fine, I'm not keen to accept it for a few reasons:

• it's a performance change without numbers or tests to back up the perf claims
• you mentioned scalability and dataset size. CCBV runs with an incredibly small dataset. All of Django's GCBVs since their release in 1.3 is really just not that much data.
• general architectural changes in the works

The last one deserves a bit more of an explanation. CCBV runs as a Django site, pulling data from a database. This made it very fast to get up and running and maintain for a bunch of Django-using developers, but it has been a thorn in our side for years. The dataset is entirely fixed. Any changes to the GCBVs only happen in a release of Django. We do not need to dynamically construct templates from the data on every request. We can write out some HTML and never touch it again (unless we feel like changing the site's styles, I guess!) The code is also tightly coupled to Django's GCBVs. There have been sites for other Django-specific class hierarchies using forks of CCBVs for years. @meshy and I have been talking, and more recently, @meshy has been doing the hard work of actually implementing the extraction of a core set of functionalities that would make it possible to generate static datasets of class hierarchies.

So, where can we go next?

To progress this PR I'd like to see some meaningful performance improvements. A difference measured in nano-seconds isn't going to be of much interest to us, I'm afraid (and I hope you can understand why :)). Alternatively, there are several low-hanging fruit tickets that you could look at instead.