Hi Joshua -- > [...] if they both implemented IPerson, IPostalAddress, and > IPhoneNumber, [...]
... and that's the point where my eyes glaze over and smoke starts coming out of my ears. I don't know you, but I'll hazard a guess at your background: Java, right? The thing you have to understand is that Django tries *very* hard to be "Pythonic", which usually means doing away with things like interfaces, components, and overwhelming architecture astronauting. Do a Google search for "duck typing"; that's how we do interfaces (as it were) around here. Now, you're right about a *lot* of your criticisms -- e.g. writing a template loader shouldn't require a spin through the source code -- but the Django way is to view that as a documentation problem, not a design issue. Database backends are another example -- they are pluggable, but almost completely undocumented. Our culture is to fix these bugs in English, not Python; suggestions that involve things like "IDatabaseComponent" are going to elicit a gag reflex from most Django programmers. In fact, just writing that word made me puke a little in my mouth. Don't worry, I swallowed it. > [...] I don't think we necessarily want to as a community try to produce > canonical, standard applications and continue expanding contrib [...] Yeah, I don't know of a nice way to say this... you're wrong; that's *exactly* what we (or and least I) would like to do. If there's a piece of code that does Feature X in way that feels consistant with Django, we very much want it to be part of django.contrib, and we want to encourage people to use it whenever possible. Django-tagging is a great ecample here. The only reason we've not expanded django.contrib more is that we've not firmly established a good process for getting apps into contrib and keeping them up-to-date. I think you're a bit mistaken about our core philosophy, so I'll try to sum it up: every single piece of code that's part of Django exists because it solves a very specific, real-world problem. We vehemently oppose adding code because "someone might need it" -- the only features that make it in are those that solve *actual* problems. If you can articulate what problem you're trying to solve (and how Django's not letting you), we might be a bit more receptive, but large architecture proposals are most certainly *not* pragmatic, and are only undertaken when they seem to be big wins (c.f. magic-removal, unicode, etc.) Jacob --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers?hl=en -~----------~----~----~----~------~----~------~--~---
