I think you can see one pilot of future decoupling with what is happening with the localflavors being split into separate repos - what we learn from this process will be valuable when/if considering decoupling other parts of Django.
Another major step is the pretty-far-along schema migration work from Andrew, which will allow for the potential of schema changes in upgrade scripts. I disagree that working on cleanly factoring and decoupling components "in place" isn't worth doing, in fact when you can add backends/plugability somewhere, and ship a BC version as the default - you've just fixed one of your "underlying problems" See for example: https://code.djangoproject.com/ticket/17093 There is no reason changes like that have to be part of a "2.0" departure, and in general talking about anything as being 2.0 related ultimately feels more distracting than productive. Anyway - as you say - progress has been made - lets do more of that ;-) -Preston On Tuesday, December 4, 2012 11:14:50 AM UTC-8, Yo-Yo Ma wrote: > > 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/-/Cm7hOv_kdGEJ. 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.
