tag:blogger.com,1999:blog-19730683.post115639227698135145..comments2023-05-15T04:39:46.735-04:00Comments on Jeremy Hylton: Inconceivable: Django PronouncementJeremy Hyltonhttp://www.blogger.com/profile/05832343974221233570noreply@blogger.comBlogger11125tag:blogger.com,1999:blog-19730683.post-1156712330465305712006-08-27T16:58:00.000-04:002006-08-27T16:58:00.000-04:00Michael: hmm.. could you then tell me how do you t...Michael: hmm.. could you then tell me how do you think it should be? like to have an universal admin-part working with any 'database mapper'? <BR/><BR/>if you don't depend on a specific database mapper, how can you do any admin-stuff? after all, you could use an object-db or a xml-db with django, which have completely different semantics than a usual object-to-sql mapper. how should all those be modifiable from a single app?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156575301338395592006-08-26T02:55:00.000-04:002006-08-26T02:55:00.000-04:00Gábor: If features like the admin interface are di...Gábor: If features like the admin interface are dismissed as mere bundled applications rather than part of the core system, then what's left of Django after you exclude the 'bundled apps' isn't very exciting.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156492453724415822006-08-25T03:54:00.000-04:002006-08-25T03:54:00.000-04:00could you perhaps describe your problems with djan...could you perhaps describe your problems with django-modularity in more details?<BR/><BR/>as Adrian mentioned, Lenz's comments very often exaggerated.<BR/><BR/>for some reason, the favourite example of why-django-is-monolithic is the ORM.<BR/><BR/>please understand that you _can_easily_use_a_different_ORM_in_django.<BR/><BR/>for example, you could use ZODB, and still use django's url-mapper, django's templating system for example. i call this modular.<BR/><BR/>yes, it's true that django ships with several "applications", one of them being the admin, which depend on the django-orm.<BR/><BR/>so, at the end, the question is what do you call django and what not. <BR/><BR/>the django 'core' is modular.<BR/>the applications written using django usually depend on what they use.<BR/><BR/>so, if there is something in django that's too 'coupled' in your opinion, please tell us which part.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156449307520123522006-08-24T15:55:00.000-04:002006-08-24T15:55:00.000-04:00I'm not sure how Adrian can say that Django is dec...I'm not sure how Adrian can say that Django is decoupled. Lenz does a good job explaining why Django is *not* decoupled despite the repeated proclomation of Django dev's. If it's so decoupled, why does so much stuff break and stop working as soon as you use a different ORM?<BR/><BR/>If its so decoupled, how come its considered impossible or way too hard to make Django compatible with other ORM's?<BR/><BR/>I'm inclined to agree with the Zope/Plone people though, if developers are looking to choose "the" Python framework, Zope/Plone have been around the longest, have a huge audience, have multiple books written on both, large lists of people using the product, the support of multiple companies, etc.<BR/><BR/>Is Zope/Plone perfect? Nope, plenty of people have horror stories, just like we see with any other framework. The Django folk say, "Drop what you're doing, help us make Django better." Why? Why don't they help make Zope 3 better?<BR/><BR/>I know they have their reasons, but it'd be great if there was some consistency in what they say, and what they do.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156443523009466702006-08-24T14:18:00.000-04:002006-08-24T14:18:00.000-04:00PHP is a good point. There is no dominant PHP fra...PHP is a good point. There is no dominant PHP framework yet it is one of the most pervasive web application platforms to date.<BR/><BR/>Second of all - the Python community can debate internally forever and respond to Rails all we want but your tax dollars are not being spent on developing applications with Django and Ruby on Rails. The U.S. government and their contractors are spending hundreds of thousands of dollars on Plone/Zope applications and training.<BR/><BR/>These agencies include NOAA, the Navy, and NASA. And that's just in the U.S. and doesn't includE the private sector:<BR/>http://plone.org/about/sites<BR/><BR/>Do any of the other frameworks in question have those kinds of proven case studies?<BR/><BR/>And if Django is the chosen framework as an answer to Rails and the Python Web Shootout then shouldn't it support Oracle and/or SQL Server?Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156441339039112522006-08-24T13:42:00.000-04:002006-08-24T13:42:00.000-04:00I don't see where having to execute your config fi...I don't see where having to execute your config file is any less stress than having one that is a simpler format. Really all you're doing is exchanging a full-featured language for a simpler one -- and while this can be a feature, in my experience any software project of significant size quickly outgrows the limitations of say the .ini file format.<BR/><BR/>As for error checking, it's still possible to make an error in a "flat text" config file that goes undetected. Ah, but you say it's easy to write an INI checker that validates that your config file is correct? Well, you can do that with a python-based config file . . . in fact, you could use unittest.MrTacthttps://www.blogger.com/profile/13783996395528458895noreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156435793231047182006-08-24T12:09:00.000-04:002006-08-24T12:09:00.000-04:00I don't think Python syntax for configuration file...I don't think Python syntax for configuration files is so bad. Using a <I>module</I> for configuration isn't good, and I think that's more of the problem for Django. The other danger to a config file is you enable people to put in funny environmental dependencies. <BR/><BR/>Personally I'm -0 on Python config files, and took them out of Paste in favor of crufty .ini files (and I think that was a good choice, ini's lameness can be a feature at times), but I can understand why someone would go the other way as well.<BR/><BR/>There was a recent project (and maybe past projects as well) that read Python-like files, but did so statically -- i.e., executing no code, but having the ability to express any Python literal. Maybe <A HREF="http://home.gna.org/oomadness/en/cerealizer/index.html" REL="nofollow">Cerealizer</A>? -- anyway, I think that would be a good compromise.Ian Bickinghttps://www.blogger.com/profile/10921115783730718101noreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156435488964196312006-08-24T12:04:00.000-04:002006-08-24T12:04:00.000-04:00Jeremy: Rest assured that we Django developers are...Jeremy: Rest assured that we Django developers are keenly interested in decoupling components. Keeping things decoupled has been a design concern from Day One, years before Django was even open-sourced. The core components *are* decoupled -- Django is just a collection of components nicely packaged together. It's all about the packaging! Christopher Lenz's comments were exaggerated in places.<BR/><BR/>It's only "shortcut" functionality, which is purely optional, that makes assumptions about one or more components being used. Frankly, I'm wary of overengineering things so that every single bit of "convenience" functionality would be able to be plugged into any other bit of code. At some point, you've gotta decide that glue is glue. At some point, you've gotta decide that an 85% solution is good enough. Diminishing returns, and all that. (In a reference to the Django tagline: Yes, we're perfectionists, but we have deadlines.)<BR/><BR/>There's a difference between decoupling and overengineering. I think we've struck a pretty good balance between the two. But, of course, we're not perfect, and I personally would like to see us, among other things, make the small changes necessary to be able to distribute Django's pieces separately. This is something we've wanted to do for a long time -- it's just a matter of finding the time and resources. Stay tuned.<BR/><BR/>Also, regarding Python config files: If you're worried about incorrect configuration, just write your configuration in INI format -- or whichever non-Python format you prefer -- and use your "real" Django settings file to parse that.Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156430615696882632006-08-24T10:43:00.000-04:002006-08-24T10:43:00.000-04:00Is this view of ambiguity in frameworks acceptable...Is this view of ambiguity in frameworks acceptable in C, C++, Java, PHP, or Perl? There are multiple frameworks for all of these languages. Why does a programming language have to have one web framework? (Maybe we should require them of operating systems.)Jeremy Hyltonhttps://www.blogger.com/profile/05832343974221233570noreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156430403528553892006-08-24T10:40:00.000-04:002006-08-24T10:40:00.000-04:00If you use Python as your configuration language, ...If you use Python as your configuration language, you've got no way to check that your configuration is correct without running it. In every distributed system that uses Python config files, this has been a problem. You push a config change out to a bunch of machines only to discover some oddball error that causes it to fail.Jeremy Hyltonhttps://www.blogger.com/profile/05832343974221233570noreply@blogger.comtag:blogger.com,1999:blog-19730683.post-1156425397776310402006-08-24T09:16:00.000-04:002006-08-24T09:16:00.000-04:00One word: Momentum.Pythoneers for as strong and as...One word: Momentum.<BR/><BR/>Pythoneers for as strong and as dedicated group we are, we are fractured... Over 10 years since 1991 and we still aren't as well know or adopted as Perl.<BR/><BR/>I say from an outside view NOT chosing ONE solid framework makes the Python movement un-sure of itself and un-marketable.<BR/><BR/>Internally, bickering about implementations is fine (who's got the biggest... um... wheel of cheese...) But for _the_ world facing view, something where outsiders are looking in, this view of ambiguity in frameworks is completely unacceptable Jeremy.Anonymousnoreply@blogger.com