Description

Much thought went into the technique used for exposing a python class to the URLconf and making it sane in the context of the View contract in a thread safe way.

However, the base class, View, is located in the generic module, implying that it is somehow tied to generic views.

I propose that this base class is a good default for anyone doing class-based views in Django, and that its use outside the context of generic views should be made explicitly obvious by relocating the location of the code outside of the generic views module.

To be honest, all classes in views/generic/base.py feel like they could live one package up. These classes and mixins are all ... uhm... basic for CBV and not specifically tied to generic views.

I think part of the issue is that the history of "generic" views were that they were only viable for the most basic of the generic cases. The current generic views are more of a toolkit, and so will be far more flexible and useful. So the word generic is perhaps no longer the best descriptor.

However I think that leaving these "toolkit" pieces in a submodule of views makes sense, while moving the fundamental implementation of exposing a class as a view-thread safe instance is worthy of being the base views module.

only the View class deals with the fundamental interaction of python classes with the Django request/response flow and infrastructure - while the other classes are just "one way of doing it" even thought those in base.py are pretty hard to argue with.