This morning read the SQLAlchemy proposal made by Luke Plant in June. I
then decided that this would be a good time to rant about abstraction,
extensibility, and decoupling.
Background
----------------
For years, Django has been forced to deal with most implementation issues
from within, including the ORM, templates, etc. Even things like JSON
support and basic timezones (for the new timezone module) were or are built
right into the framework, in order to handle heterogeneous environments and
Python versions, and to minimize external dependencies. This strategy
contributed to the success of Django, in part because finding nice, well
supported libraries was tough, and installing dependencies was too.
The Python community has grown and its processes have matured nicely.
Nowadays, for a given problem, there are typically multiple solutions, many
listed on services like www.djangopackages.com. Installing packages is
easy, thanks to things like pip, and pypi. Collaboration is simpler, thanks
to services like GitHub. This trend can be summarized as abstraction, which
is a good thing. Handling things at a proper abstraction level is always a
time and heartache saver, and is of course the reason for using a framework
like Django in the first place.
The Problem
-----------------
Solving too many problems from the top down, and coupling things too
tightly in a project leads to code rot, because implementations all have to
be written by somebody who is intimate with many other parts of the
framework, then they have to be vetted others who are intimate with many
parts of the framework, and then the code has to be maintained. Coupling
becomes an inevitability, simply because it is possible. Backwards
compatibility becomes more and more difficult and costly to maintain, and
prohibits growth. Projects built atop the framework eventually run into
problems for which the solution is to make changes to implementation
details (usually via subclassing, but in some cases, via monkey patches),
which leads to code debt in a project, and subsequent contention in the
community when implementation details are changed in a way that breaks
backwards compatibility for those "power users".
This means that the issue of "We can't do that because it'll break things"
isn't really the problem that Django has. It's a symptom of another
problem, which is that Django is not nearly extensible enough (it's parts
are not pluggable enough, and or are not well enough abstracted to be
quickly changed and/or moved).
So, what?
-------------
So, Django has evolved toward being a more decoupled, less monolithic
framework over the past couple years (e.g., the removal of auth's coupling
to things like messages, customizable user models, etc.), but there is a
lot left to be desired. I consider a Python web framework to be a minimum
of A) request handling, B) URL routing to something callable (a view), and
C) response handling. However, certain other things are good ideas to bake
in, such as cookie handling, security related features (CSRF, click
jacking, etc.), and probably a few others. Anything else should be
completely pluggable, and completely decoupled from everything else.
Some examples which make me smile:
Sessions -
Cache - includes support for plugging in a back-end and only defines a
simple interface (cache.set, cache.get, etc.)
Mail - includes support for writing / plugging the back-end of your
choice, only defines a simple interface (send_mail, send_mass_mail, etc.)
Some examples which make me sad:
Templates - unpluggable (importing a third party template library and
using it in your view is not plugging it in, since this isn't compatible
with 3rd party or contrib apps)
ORM - I'll defer to the complexities that arose from Luke's proposal
Admin - lacks abstraction, and therefore has some great tools that
can't really be used elsewhere (e.g., filter specs, sorting, etc.), lacks
usage of CBV, in favor of an ad hoc solution
The Solution
-----------------
>From an interface perspective, I have some ideas about how to handle the
templates side of things, and some pretty vague ideas of how to handle the
ORM, but I personally think that the real solution is to work not on
implementing new ideas and solutions to use beside or in place of existing
ones, but rather to fix the underlying problem that Django has. We can
fight an uphill battle constantly by trying to usher new ideas in over our
12 foot wall, believing that it is indestructible, or we can work together
to "Tear down this wall!" :)
Remember, we're at 1.5 now. If we have a specific goal in mind that is very
drastically different now, we can do a lot before 2.0 without breaking
backwards compatibility (at least not too badly).
--
You received this message because you are subscribed to the Google Groups
"Django developers" group.
To view this discussion on the web visit
https://groups.google.com/d/msg/django-developers/-/a5LL7K1TXisJ.
To post to this group, send email to django-developers@googlegroups.com.
To unsubscribe from this group, send email to
django-developers+unsubscr...@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/django-developers?hl=en.
