all caching-related code should be collected into its own cache application

[Gary Wilson <gary.wilson@…>]

There are various modules related to caching spread throughout the django tree. They should be collected into a "cache" package/application.

[Malcolm Tredinnick]

Gary, can you provide a few more details on where the scattering is? It sounds like you already know the details. Not easy to make a decision on this without more information.

[Gary Wilson <gary.wilson@…>]

./django/core/cache/
./django/views/decorators/cache.py
./django/utils/cache.py
./django/middleware/cache.py

[Gary Wilson <gary.wilson@…>]

The ​Object-level caching Summer of Code project makes an even stronger case for a cache package. The author has proposed adding a caching app to contrib, but I suggest we put everything into one cache app.

[Gary Wilson <gary.wilson@…>]

Moved cache related modules into a cache package

[Gary Wilson <gary.wilson@…>]

Renames:

  django/core/cache => django/cache
  django/middleware/cache.py => django/cache/middleware.py
  django/utils/cache.py => django/cache/utils.py
  django/views/decorators/cache.py => django/cache/decorators.py

[Jacob]

I agree that the four different "*.cache" modules are silly, but this'll break a lot of user code just for a bit of cleanup. So here's the $1 million question: is the code churn and renaming "worth" the cleanup?

[Jacob]

After talking with Malcolm, it just doesn't see like this is worth the breakage.