I don't really know how to respond to this other that "patches welcome". You're proposing very vague, sweeping changes with no details. That just doesn't work around here; if you want to make a big change you have to actually bring some hard work to the table. I think I probably agree with you in theory, but if you're serious about this and you want my help you need to show me some code.
Jacob On Tue, Dec 4, 2012 at 1:14 PM, Yo-Yo Ma <baxterstock...@gmail.com> 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/-/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. > -- You received this message because you are subscribed to the Google Groups "Django developers" group. 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.
