[murkt]

Class-based views were a problem when they were introduced in Django, and they’re still a problem.

Especially for the so-called AI-ready framework. Because of indirection, you either have to go read all the basic classes, or read documentation three times over. Instead of just reading the self-contained view function itself, once.

Especially true for an agent, it will have to go read the new framework’s docs and source over and over and over…

[strogonoff]

There are very specific reasons to use Django’s class-based views, so much so that it doesn’t really strike me as “multiple ways to do one thing”.

Case 1. You are simply writing a view. Request comes from the router, you want to run some logic and return a response. Either it is part of the end project, or it is simple and small enough that the end project would prefer to just override the entire thing. Write a function!

Case 2. You are working on an end project, and you want to take a view shipped by Django or some library and override bits of its behaviour. The view is already shipped as a class, and writing it as a function would be unwieldy because there is a bunch of logic you’d need to repeat. No-brainer: just inherit and go.

Case 3. You are writing a library that is intended to be customised by the end project. You ship a view that performs a somewhat complex sequence of actions as part of handling a request (e.g., validating input, constructing a query, fetching a QuerySet, serializing it in some way). You want to give the end project an easy way to borrow your view and override only specific parts of that logic. Consider writing a class-based view, and basing it on some pre-existing class-based view if possible (the above looks a bit like ListView, for example).

[murkt]

In my experience, your Case 2 plays out a bit differently. "Just inherit and go" and in many cases you end up with more lines of code in total than doing the same thing in my own function with some kind of helper. Even in the dead standard thing, like displaying a list of objects with pagination. But now I don't own the flow!

Any kind of customization and I need to go jump through the hoops, I need to go look at the code what exactly happens there. But this class inherits a couple other classes, and I need to go read them as well. What for? Grug not want read seven basic multiple-inherited class just to display a list of objects.

So I disagree that it's a no-brainer. It's a no-no brainer for me.

As for writing the libraries, I have the same problems with all libraries that provide class-based API, where I need to inherit from libraries' classes to do my thing.

I like my code to be stupid and linear, to own the flow, so I can read the code and understand what happens there. Same is true for agents!

I am also willing to accept some LoC penalty for my approach. But it's shorter in practice, so win-win for me.

I was using Django since 2006 up to ~2012, and then again touched in 2014-2015. Never again.

[strogonoff]

If it’s easier to just write a function view, then sure, just write a function view. I did phrase it specifically: if you want to take stock logic and just override a specific part, then CBV is a pretty intuitive way of doing it.

My point was mostly: stick to function views by default, don’t bother devising your own class-based views in an end project, maybe do if you ship a library and have carefully thought about extension points that are ergonomical for your users, and do take advantage of a pre-existing CBV if it feels like a natural, sustainable, low-LoC solution.

For example, as a default choice, if I need to show a list of items, I would in fact just write a function view. However, once I need more features (the turning point for me is probably pagination), I’d brush up on the docs, subclass a ListView, and enjoy well-tested logic taking care of things for me. In the simplest case I’d just set class attributes without overriding any methods at all; maybe I’d take over get_context_data() to give the template some project-specific variable that doesn’t make sense in context processor. If I need something significantly more custom, I’d switch back to a plain function view and use in it pagination primitives that Django exposes. Done all of the above at different times and I think it worked pretty well.

Yes, it did come with practice and I did ship some spaghetti at first, but I also was a relative noob/junior when CBVs came out.

Fine, it is subjective, so there is more than one way of doing things here, and it is not great, but I still think CBVs have their place.

> I don't own the flow

Sir, this is a framework, we don’t own the flow. (I’m slightly jesting.)

> I like my code to be stupid and linear

I am in the same boat, but to me overriding a CBV method seems pretty stupid.

I used Django for from pre-1.0 (the latest time was in 2021 and that project is still live), been to one PyCon and contributed some really minor fix or two. While I have seen hairy Django codebases, I still think it’s a very sane and the best-documented framework.

[drchaim]

that's so true, I still prefer function based views