Wonderful! I just want to extend a heartfelt "thank you" to all the guys and gals contributing to Django.
Django is still a cornerstone of our startup and we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM and all the built-in tools (not to mention 100s of libraries that get you an 80% finished feature in 5% of the time).
I hope to meet a lot of you at Pycon, I'd be happy to buy you a beer. I'll be wearing the bright orange Zapier shirt, you can't miss me. :-)
I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple. Django has a monstrous "middleware" piece and a bunch of other cruft that is really just bothersome dead weight. It's not that there's no use for it, it's just that similar things are accomplished in much more concise, fast ways in other frameworks.
Not to hate on Django, jacobian, or the LJ-World, I appreciate the effort put into the system. But I don't think it really has much to offer in present-day for people developing new, serious platforms. I feel the same way about most other "full-fledged" MVC frameworks, because they all seem to far exceed what ought to be the logical bounds of their influence. In many cases you feel like you're writing Django, Cake, or Rails and not writing the actual language based on, because these frameworks mandate so much and require special integration to do much of anything. In something like Pyramid, you write Python, and Pyramid provides the pieces that make it easy to bundle together and publish as a website.
I've had positive experiences with Sinatra, too. "Microframeworks" and close cousins like Pyramid are really much more appropriate dev platforms, imo: modular, unpretentious, exist simply to help you get your program onto the web in a fast, concise, and simple way, without attempting to inject a rewrite of the standard lib or force you to conform to their unique flavor of MVC, their crappy ORM, etc.
I develop a new, serious, widely-used platform and I love Django. I've definitely been around the block, have developed python-based web apps without frameworks, etc.
I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.
>I've never had an issue with Django being inflexible. The strong conventions and the fact I don't have to make a decision about every little thing makes me, and the ecosystem, more productive.
I don't really understand this. Other frameworks don't require you to "make a decision about every little thing" either. It's not like they're just a blank file that says "<WRITE FRAMEWORK CODE HERE>". They come with defaults, things that are in place automatically. They come with suggestions and recommendations for optional stuff. They come with docs and tutorials. They just don't make illegitimate mandates, they don't revolve around a specific ORM or a specific template.
If you start a clean Pyramid project with the "alchemy" scaffold (recommended) right now, you'll have Chameleon, SQLAlchemy, and URL routing automatically chosen for you. You don't have to make any more decisions. You just have to open up views.py and start coding.
To you it may be "illegitimate mandates" but to a django dev it's a blissful ignorance. You might just have to agree to disagree.
Let's say you want to add a column to your database. Because the django ORM is so popular and monolithic, it has amazing tools for the job that do it auto-magically when you modify models.py. And that's just one facet of many.
For some folk, the flexibility of Pyramid is nothing but a bother.
No, because you don't have to use the flexibility. Pyramid comes with defaults. You can blissfully just use what comes out of the box, or you can, relatively easily, use something else. There is no cost to the programmer who simply wants to ignorantly use the default tool set.
I've used pretty much all of the major python frameworks in a professional capacity, and have also dipped toes into the RoR world as well as the various php frameworks. Django isn't "the one true way" - I've been known to reach for Tornado often - but it certainly works (ORM, templates, middleware included) for the majority of projects I've undertaken, and I've had success advising others to adopt it.
Also strange to hear that Django has a unique style of MVC, it seems pretty standard to me (and from what I see a lot of new frameworks are aping it).
> Also strange to hear that Django has a unique style of MVC, it seems pretty standard to me
some people are confused because of the semantics (view is controller, template is view). in the end, as you say, it's still (yet another flavor of) MVC.
I don't intend offense. I'm just suggesting an explanation for why you may feel Django is not problematic. When all you have is a hammer, everything looks like a nail. I've met many-a-programmer fairly early in their careers who praise things like Cake, Rails, or Django, but in my experience at least, as they mature, they prefer less invasive solutions.
My 2 cents in response: I use C#, JavaScript and Python daily. I spent 6 months learning Ruby but decided it wasn't for me. I also use Objective C for iOS and enjoy optimising SQL in my database layer.
However the three platforms I use in order are .Net MVC, Django and node.js. Before I chose Django I wrote my own Python-based web framework but decided I'd rather build applications than frameworks. Django has a massive community built around it that I couldn't find anywhere else (note - I _have_ been using Django since 2007).
The main reason I use Django? because I, personally, know what I'm doing, where everything lives and can get it done quickly. It works for me and it clearly works for other people, so you can't knock it.
What I _wouldn't_ do, is advertise for a 'Django' developer. You have to know Python and understand what your framework is doing under the hood.
Django is great, I'm sure Pyramid is great as long as you understand what it's doing and have read the code, but most importantly, what we all are is Python programmers.
In a few years you'll probably get to the point where you don't prefer less invasive solutions but will pick the right tool for the job.
If you know you'll be iterating rapidly but will stay within the confines of 'standard CRUDdy app' then e.g. Django, RoR, Spring Roo e.a. will be probably be good to you. If you expect to go beyond those confines you'll be burnt.
In general it's about finding what I like to call the 'grain of the tool' and pick the ones where you can go with the grain.
I prefer less invasive solutions because they are generally the right tool for the job for serious web platforms, which is the niche to which I limited my comments. And for the record, I've been around for some years.
If I just want a basic CRUD app that will basically never exceed the capabilities of Django's automatic admin interface, then sure, Django will be fine for that because all I'll have to do is define models and I'll be done. I can then query the SQL database directly if necessary, or write a separate application that generates reports on the data.
Most "serious platforms", however, do much more than this. For platforms that run companies, least-invasion is a good principle, because it allows you to adapt quickly as changes are necessitated. Django, Rails, et al often world-break if you try some "funny business". Next-gen frameworks like Flask and Pyramid have almost no reasonable condition that qualifies as "funny business" from the framework's perspective, so they're much easier to iterate upon or pivot from.
> serious web platforms, which is the niche to which I limited my comments
That is exactly the kind of grain I was talking about.
If you were running a startup that's focusing on finding product-market-fit and quickly iterating on the UX to get conversions up and attrition down Django (or RoR) might be a better fit.
When you start outgrowing Django you can just start splitting off components and rebuild them in a more 'serious' way.
you're doing an terrible job explaining your beliefs. you come across as mostly incoherent with an ideological obsession with "unobtrusiveness". to me that sounds like an indicator of a barely contained case of not-invented-here syndrome.
maybe you can explain your language more explicitly and help alleviate the bad impression I (and others) have got from your posts. what is a "serious" web platform? how is django less appropriate for "serious" web platforms than Flask or Pyramid? can you give an example of something breaking due to django "funny business"? it would help if you gave a real example. i've seen people complain about this alot but i've never seen an example of it causing any more problems than an annoyed developer having to do it django style instead of whatever way he/she wanted to (due to ideology).
Just as a note to everyone, you can use Mako/Jinja2, SQLAlchemy and really any other Python tool/library out there with Django.
What Django does well is provide a pre-built and (IMHO) easy to use set of default tools. This does not mean that you must use these tools, they are just there by default if you need them. You could really just use Django as an HTTP routing tool.
I admit it's been a while, but when I tried django-sqlalchemy in the past, it was not in a pleasant state. Last I came around, it was certainly not just a simple drop-in thing.
While I'm sure you're right that it's not a hard requirement in that you can figure out how to make it work, it's not an easy thing, and you'll be fighting the framework and the conventions all along the way as interdependent stuff stops working. Again, in my experience. If things have improved significantly, I'd like to know.
When toys ship "batteries included", it's easy to pull them out and replace with a different brand, if you want. Django, and most other web frameworks, don't make that interoperability a serious concern, afaik. When you use a framework, you are essentially adopting its code into your project all at once, and you become responsible to make sure it works and adapts to your needs even if upstream dies out or makes a decision that renders new versions unusable for your use case. "Non-removable batteries" are therefore a major design flaw in your project, even if you haven't had occasion for it to be exposed yet. The batteries of monolithic, "opinionated" web frameworks like Rails and Django may be partially removable, and maybe they've improved recently, but newer frameworks like Flask and Pyramid don't have this issue at all, and it makes them much more flexible.
Just wondering if you have any tips (that you recall) for making django and sql alchemy work together. sql alchemy seems like the best ORM to work with and django has a nice ecosystem. If sql alchemy only does read operations on django models, will that make the integration simpler?
For people developing new platforms I think Django has a great deal to offer and should be a serious contender if you are looking into Python based web frameworks.
A few specific things I like about Django:
1. A decent app ecosystem
2. Lots of documentation and a fairly mature codebase.
I never really loved them until I started working on a massive Django project with Oracle. South doesn't support Oracle, and now I have to manually tweak tables every time I update a schema.
The company I work for just switched _to_ south from a custom migration system and it has been really awesome. It streamlined out development process a bit as well.
He never said they were specific to Django, he was mentioning a few specific things he liked about Django.
It's great you like Pyramid, but honestly, a lot of this is just a matter of taste. I personally find the way Pyramid fits together and its documentation less appealing than Django. In my dabblings with Pyramid, I found the community less responsive and helpful. But that's all subjective and anecdotal, just like your take on Django (which is why this is a boring discussion).
The truth is, good engineers can do great things with far less than Django or Pyramid. The choice of framework is a very boring discussion, since most modern, widely used options are going to be "good enough" in the right hands. Your idea and its execution are front and center. If you're sufficiently skilled, your framework shouldn't be a huge factor in your execution.
Pick something that you like, and just get to work.
Right, I never said it was impossible to build something useful in Django. I just believe it's a non-optimal choice, in almost any situation. I don't believe "it's just a matter of taste" to have a web framework that knows its place and makes it simple to adapt, or unpretentiously allows you to code with minimal rigidity. I don't find any contrary arguments presented thus far convincing.
Saying that Pyramid's documentation and overall "fit" is "less appealing" is a matter of taste. Indicating that Django is much bigger is a matter of fact, and that it provides little if any additional benefit and increases rigidity and practical obligation to conventions is a matter of informed analysis. The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived. it's nothing personal to Django or the people involved in it (I've even submitted patches, but to my knowledge, they were not merged). It's just a thing that has been superseded, and that happens in tech. Now it's just a matter of how long until everyone else can drop the religion and admit they're wasting time on compliance and rigidity that shouldn't be there.
I'm not saying Django is the least productive framework in existence. I'm not saying it'll ruin your company or life if you use it. I know people who use it and we are able to get along. I work with it occasionally. I'm just saying, "it's unwise", for almost any large-scale new project.
> I just believe it's a non-optimal choice, in almost any situation.
And this is where your argument loses every bit of credibility, this is an awful, unsubstantiated blanket statement. I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
> The argument to be made, then, is why that obligation and rigidity and bigness are valuable, which thus far, no one has really done.
I think you're missing the point entirely. Your claims of rigidity aren't applicable for everyone. For a very large number of users, Django doesn't need to be super de-duper modular/interchangeable (it's good enough for many/most). In fact, some people don't want the complexity of SQLAlchemy. Some don't even know/care what jinja is (I personally haven't felt the desire to switch to it, as I feel it has problems of its own).
Django is batteries included. Pyramid is not. These are two different approaches that each have tradeoffs.
> It's not necessarily Django's fault. Pyramid is a much later framework, and alternate implementations of pieces of the full stack like Jinja2, Mako and SQLAlchemy became mature after Django was initially conceived.
Again, not everyone wants these pieces you are talking about. While SQLAlchemy is a great piece of a software, it is a complex piece of software with a steeper learning curve than the simple Django ORM. There are plenty that don't need/want something as heavy duty as SQLAlchemy. In my case, if I need the absolute best performance or advanced features, I am writing SQL instead of dealing with any ORM that makes bad choices for me. More ORM is not attractive to me, I tend to dislike them for anything but the most simple cases (ie: the basic Django ORM operations).
That is where your blanket statement falls to tatters. Differing requirements, different priorities.
> I'm just saying, "it's unwise", for almost any large-scale new project.
And not all advice is created equally :) I'd say that it is appropriate for some large-scale projects and teams, and inappropriate for others. It's flat out wrong to make a blanket statement like yours.
No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
If you want simple, you can use adaptive frameworks simply. They come with defaults just like Django does. The difference is that it's easy to swap or mix-and-match components, and it's an intended use case. On Django, if you don't go with vanilla, it's a hack.
As I wrote elsewhere, "batteries included" doesn't (or shouldn't) mean "batteries hard-welded". It's fine to include stuff and have defaults; adaptive frameworks have these too, but they considered the fact that someone may want to do something irregular at some point and that it shouldn't be a world-breaking experience for that to happen. A framework that understands its place is all gain, in that it doesn't intrude and try to force something, and no loss, in that it also comes with defaults that you can just use if you aren't yet at a stage where you'd have a reason to replace them, and therefore, from an objective technical standpoint, it is a better choice. Perhaps social issues override this in some situations, but those can't be considered in our removed, objective, technical context.
>I'll be the first to bemoan Django for its flaws (it has many, as do all frameworks), but this is absurdly misguided thinking. There are tons of success stories to the contrary, with new ones adding to the pile every day.
It doesn't matter if there are success stories. I'll repeat myself, I guess, and say that I don't intend to say that Django is useless or terrible or that it does nothing and will ruin your life. The point is that most people who choose Django for technical (not social like "we all already know django") reasons are making an incorrect choice. For now "we all already know django" is acceptable, just like "well we all already know SVN" was, but at some point it won't cut it anymore, and you'll be expected to adapt.
>Django is batteries included. Pyramid is not.
I disagree. Pyramid comes with batteries. It has a full stack ready to go for you if you just want to open it up and code, just like Django does. The difference is that Pyramid allows you to tweak or swap freely as necessary, and Django makes it difficult.
>It's flat out wrong to make a blanket statement like yours.
No, it isn't. My blanket statement is generally but not all inclusive. Is it wrong to say "Using Windows 2000 as the primary hosting platform for new projects is almost always wrong"? Things change in tech. Rigid generic frameworks that try to dictate templaters and ORMs are old hat, they are plainly incorrect for all but the most esoteric use cases. There is no good reason to do this.
Is Django going to disappear overnight? No, but I hope that people can get past their holy wars and take a serious objective analysis. Consider that you're actually against a useful feature set just because the less-powerful solution is often "good enough". That's not a reason to choose a thing, it's just a reason not to flee from a thing. I'm not saying every Django app needs to be rewritten, but I do think it's silly to settle on "good enough" for new stuff when "much better" is available at little or no downside.
> No, I'm not sure why you're so dedicated to promoting Django's negative qualities as if they're virtues. The rigidity is not preferable, in any circumstance. It's simply less adaptive, and therefore less useful, architecture.
This reminds me of when ROR came out and "opinionated frameworks" were the new black. I can kind of see where parent is coming from - lightweight frameworks are lightweight because they rely on external components (eg, ORM, form-handling libraries...) which are so many moving parts, and not always well integrated with the framework. On the other hand, I've found that the Flask plugin ecosystem works pretty well as very lightweight glue with other components.
And let's face it: even with a "batteries included" framework, you'll eventually have to go out and get a third-party battery which was not included.
Django rigidity with the ORM and template language brings one major advantage: Reusable applications developed for Django are pretty much guaranted to use them. So you can aggregate them without having to deal with 3 different ORM or template languages.
Yes, django reusable apps are not always top notch quality and always maintained properly. And sometimes you will need to dicth all the templates and create your own. But you sometimes get an important piece of software for free or at least a good base to start your work.
I feel that with a more "flexible" framework the integration of apps coded by different teams will be more problematic.
I'm sorry, there are just too many absolutes and far too much hyperbole in your response for it to even be taken seriously.
This "Rigid" term you keep throwing around is absolutely ridiculous. It seems to be the entire basis of your argument, but you fail to back it up at all. Django makes some decisions for you, but you can almost always go another route. It's all just Python.
"<Vague blabbering about 'rigidity'>. Boo Django, yay Pyramid!" - cookiecaper
The problem is that someone has to create that project as anything more than a shim in the first place. There is no reason a generic web framework should require a full-fledged compatibility effort to switch out what should be "just another library". Note that there are several incompatibilities with "true" Jinja2 at the bottom of that readme, and that support for built-in "Django tags" is necessary.
This is far less adaptable than Pyramid, which makes most internal functionality like that accessible via the request object, which can be accessed by your template language's typical variable evaluation syntax, and which can use Mako or the default Chameleon with just a one-line configuration change, or Jinja2 and others by installing a simple shim layer that is mostly boilerplate.
Personally, I've tried to use mako with django and found it unwieldy to pass the correct information across the controller-template barrier. This was some time in the past, however, so perhaps either the adapter or documentation has improved and the problem no longer exists. The real issue, however, is that a generic web framework would make it difficult to replace unrelated user-facing libraries in the first place.
Given the callback nature of the Django templating library with template tags, includes, and other goodies, it is not as simple as "call foo_template() and return string". As soon as a template tag is involved, internal data structure needs to be exposed, with makes * everything* much harder.
Jingo serves purely as a minimalistic bridge between Django and Jinja2. Coffin attempts to reduce the differences between Jinja2 templates and Django's native templates.
If separation of duties is a concern, Django's templates (IMO) get it more right than anything else.
I remember, at one point, that I felt Django templates were limiting me, and started swapping them out piecemeal for Jinja, and my designers started to absolutely hate me. Not because they had to convert anything, I converted everything by hand, but just that the amount of syntax you can cram in there keeps everything less pure.
Since then, I realized I was trying to do too much in the template and started putting things where they belonged, and now, whenever I work with Jinja or Mako, it feels a little too much like editing Wordpress themes or something in PHP.
Long story short, I learned the hard way that if you're putting logic in the templates, you're probably doing something wrong, and I agree that it is not only a reasonable design, but a very good suggestion as well.
I built http://www.modewalk.com/ from scratch using Django. I do have "plenty of exposure", and the default template engine worked just fine. The default ORM is just fine. Most of the defaults are just fine.
Hey, very interesting site indeed. I had a few questions about what other stacks/technologies you've made use of. Drop me a line or two on rashid.aden.omar@gmail if you could. Thanks
Again, the issue isn't whether "the defaults are just fine". It's a larger design problem, where a framework makes illegitimate assumptions and imposes illegitimate requirements, making it difficult to swap out components that shouldn't be mission critical. This is excused as "opinionated design", which, as I explain in another comment, is another way to say "bad design with an attitude".
It is very easy to say "Django has large design problems" and go on about how it "imposes ilegitimate requirements". Truth is that Django is a framework and by definition, frameworks give you a way/structure to do things. If you don't want a framework, then there are several other options.
The strength of Django comes from the huge quantity of packages you can swap in/out. You mentioned you don't like the Django Template engine and that Jinja s better. Easy to swap. Don't like the authentication? Swap it out for something else or use a custom one. Don't like the ORM? Dont't use it... sadly you'll be missing out on south which has saved me from sql schema and data migration headaches. Caching? Redis, Memcache, or write your own. It plugs easily. Async processing? Celery is only a few lines of code away. Indexing with Sphinx search or Lucene is trivial. Want to add automatic CSS/JS minification + bundling + sprite generation + cache busting? There are django apps for that. Need analytics? You only need two methods for middleware. I could go on forever... The point is that this is exactly what I expect from a framework. If the framework doesn't do it, the somebody has to - and that means it is me.
It's about the rigidity of the structure given. A framework is supposed to give me the tools and structure I need to do what I brought the framework in to do. On a web framework, that is to pipe I/O over the web, give me access to web-layer stuff like the request object, and provide a few other simple structural niceties like MVC (which itself is quite flexible in Pyramid (optionally, of course)). I don't want it constraining me to the point where the world breaks if I decide the default ORM or template is not making the cut.
As for all the things you've mentioned, it's perfectly plausible to have those things occur in Sinatra/Flask/Pyramid/whatever. The structures they provide are sufficient to hook up the kind of things you've mentioned. It's only that smaller communities have fewer pre-packaged solutions. In most cases, if you're building a new, serious platform, you'll want to use something that you can believe in technically, even if initially you'll have to contribute some of those modules yourself. You must be willing to invest in things you believe in, or they will die.
I am sorry, but I am still failing to see your point. Let me address the specifics issues you brought up:
Accessing the request object? In Django, there is a RequestContext that can be accessed all over the place (e.g. middleware, views, templates or wherever else you wish to pass it through). It has many helper methods that parse several thing only one method call away.
The template engine? I have used Jinja in some projects with Django. It literally takes less than five lines of code to swap out. Look it up.
The Django ORM? Don't make the calls. I have done a handful of projects where doing everything through the ORM would have been a really bad decision since the web app was mostly about being a front end for an analytics system with processing that took from hours to days to complete. Instead, I wrote raw PostgreSQL/PostGIS SQL queries all over the place that ran asynchronous and hooked up Hadoop Clusters for other items... everything being controlled through django-celery. It was really easy to do. The state currently uses it to do "serious" pollution, health and city growth analysis, hence why I fail to see your point.
You mentioned Sinatra/Flask/Pyramid and such. Thore are good frameworks, but you also acknowledge that there are "smaller communities in few cases" and my point is that is exactly where django shines: the ecosystem.
I like to build "new serious platforms", too. To do that, I use whatever is appropriate from Django and the community and I have yet to stumble upon something that keeps me stuck because of the decision I made.
Granted, it is a hammer and sometimes you need a drill. Let me give you an example: One of the apps I needed to write is a realtime geolocation service. For that, I use websockets and node.js because of its non-blocking and persisted connection nature. Does that mean that I need to ditch Django altogether? Hell no, I let the front reverse proxy direct the websocket traffic to node.js and the rest to django. My node.js code is so tiny because it is just a Pub/Sub client proxy. Most of the work is done in async Celery/RabbitMQ workers (that use the Django ORM by the way). Doing this with Django is easy (well, to be fair, the credit should go to the vast amount of python libraries).
I "believe [in Django] technically"... why? Because in the four years I have been using it I have yet to get stuck because of my decision to pick it. I don't use it for everything, but I do for 99% of web related work. Once again to the risk of repeating myself, I pick and choose the Django parts I need in a per-project basis. Funny enough, I still laugh everytime somebody complains about some performance thing and I pretty much see their face jaw drop to the ground when I install varnish in front, change two lines of code to tweak the expiration headers, and deploy the static content with a good CDN. 5x performance is not surprising. Yes, there are several Django apps that make this trivial to do.
Sorry I still don't see the specifics of the points you are trying to make.
Opinionated design is not "bad design with attitude". You may disagree with the opinons, but those opinions are thought through and made for the best interests of all the users. It is not uncommon for you to sit in the outside the "norms" the framework is shooting for, but that is not a problem for either you or the framework. A framework that tries to be all things to all people generally sucks for everybody.
>A framework that tries to be all things to all people generally sucks for everybody.
Right, I agree. I like a framework that tries to be a generic web framework for most people who want to write a typical web application in Python. That seems adequately specific to me. I don't consider that "opinionated design", it's simply identifying a market.
"Opinionated design" is an excuse to make interopability and cross-compatibility difficult. There are, generally speaking, few good reasons to do this. Things that are totally out of scope obviously shouldn't be integrated, but if you feel the need to bundle a certain type of library with your framework, shouldn't it be sensible that someone might want to tweak that someday, or replace it with another library that does the same thing in a different way? Opinionated design is about copping out of that logic and putting a smooth sheen on it, it's saying "OK, we understand this is a reasonable, in-scope requirement, but we're opinionated and cool, like Steve Jobs, so we're just going to say you have to use this library or you're SOL. Remember, we are cool like Apple, and that's why we can tell you off in this fashion". Not "only projects that implement this prudent, adaptive, and objectively important-for-our-use-case protocol will work", but "only this library" or "only this way".
Projects that don't suffer from scope creep or far-fetched, irrelevant integration aren't called "opinionated design", they're simply called "well-managed". It doesn't come from having an opinion and telling everyone else to shove it. It comes from having goals and the discipline, reason, and structure in place to stick to them.
>I wonder if perhaps your people just don't have much exposure, because the templating in Django is awful compared to Mako/Jinja2, the ORM in Django is awful compared SQLAlchemy, and most of the useful features of Django are easily available in Pyramid or Flask, yet these systems are unobtrusive and simple.
Define awful in concrete terms.
I've not been much constrained by Django in any way.
Even if all of those are "better" in some spec-listing way, Django could still be better by offering better integration for it's tools.
Like the iPhone, in actual use, beats phones that are better than it "spec-wise".
Really not a fan of this terminology, popularized by DHH/37S. The term "opinionated design" is basically an excuse to make a rigid, unadaptable behemoth, because it's easier to just say "if you don't like it, you don't have to use it" than to address some of the problems. There is a balance, of course, and you can't spend all your time abstracting out to support the most transformative, irregular use case, but something like mixing ORMs or templating languages is actually a great example. Look at Pyramid v. Django/the others. A web framework should simply be about piping your program's I/O to the web. Templating and ORM shouldn't even be in scope. Having reasonable defaults is fine, but claiming it's OK to tightly couple your general-use web framework with user-facing unrelated libraries as hard dependencies (i.e., forcing users to use a certain ORM/templater) because it's "opinionated design" is silly. It's simply bad design.
> A web framework should simply be about piping your program's I/O to the web [...] Templating and ORM shouldn't even be in scope.
nope. that's what a server gateway interface is for. giving you a set of reusable tools and conventions to help you work - that's what a framework is for. the scope of the framework can be wider or narrower and it depends what you like - it's just, like, your opinion, man. the so called microframeworks are cool, but they are not a remedy to every problem out there.
> forcing users to use a certain ORM/templater
forcing? not sticking with the defaults and building an exotic combo leaves you out of re-using a lot of the ecosystem apps, but certainly you are not "forced" to do anything.
I think it's important to note that not everyone wants or needs to choose every single component in a project. In fact, this can be a big waste of time and added complexity for some projects, particularly the more simple ones. Even for a larger project, your choice of template language is nowhere near as important as the quality and cohesiveness of your overall design (you know, the actual important stuff). With the move towards heavier API-driven client-side stuff, the choice of frameworks gets to be even more boring.
Django is easy to hire for, it's easy to get help for, it's easy to Google around for. I can plug in an intern and have him productive very quickly due to the great documentation, and the "opinionated" nature of Django (there are widely known best practices for lots of things) is great in this case. He doesn't have to wade through all of my glueing of pieces together, figure out this lesser known, lesser documented, lesser supported framework (Pyramid). He just says "Oh, this is Django, I get it."
I don't make the claim that Django is better than Pyramid, but I think it's probably foolish to do the reverse as well. They are just two different ways of doing things: minimalistic/bring your own lunch versus batteries included.
And you lose a lot of the benefits of Django, to be fair. We use Jinja2 on DrawQuest but it was a bit messy to add back features like the Django context processor.
I'd love to hear more. We are considering Django with Jinja2, primarily because I think some of the Django template opinions are a bit wrong. I don't want to fight one direction in my efforts to keep from fighting another, though. I'd prefer the details I know. :)
Every time I find myself in another platform, working away, there is always a point where I stop and say to myself - I wouldn't be doing this if I was using Django.
> I wonder if perhaps your people just don't have much exposure
Having used and rejected each of the things you mentioned for various reasons, I think you're making the common mistake of assuming that other people have the same challenges and preferences you do.
It's particularly pointless to do this in a project release announcement thread – if it really doesn't work for you, just skip over it rather than flaming.
the only thing I agree with in your entire post is criticism of the django template language. its a pretty bad system that encourages sloppy work arounds. jinja would be nice. fortunately the template system is one of the easier things in django to swap out.
i think you're wrong about the ORM. django's ORM is actually really good, its just that the api is optimized for different use cases than SQLAlchemy. django ORM does a better job of simplifying the most common queries. its worse at complex queries. thats a reasonable trade off and i think you go way too far when you say its "awful".
> we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM
Well, that means you are not past that point. First you learn to love your tools, then you learn to hate them, and it's ok.
It's not really that hard to reach the point where the orm pisses you off (examples: https://speakerdeck.com/alex/why-i-hate-the-django-orm by core dev, there is a talk somewhere on pyvideo.org), especially if you have actually written some complex sql queries in your life.
Honestly, it's more of a 98/2 case for most business systems. Writing complex SQL for that 2% hasn't bothered me particularly thus far. And for simple (and not so simple) joins, the syntax is lighter than SQLAlchemy.
I'm not saying the critique is bad, it's just that in practice it's not something you'll be noticing day to day, and if you are, switching to pure SQL or SQLAlchemy is not a bad alternative (and Django makes that very easy to do).
Sure, I'm currently doing a project with SqlAlchemy in Django (I went pure SqlA in there, but there is Aldjemy if anyone wants to just occasionally extend their query capabilities on top of Django's objects). There is no doubt Django orm is easy for most web crud cases, but also you have to admit that many queries that are trivial to write in pure sql take some weird gymnastics to implement using the orm (Q, F, extra, mapping raw_sql - yuk) - that's what I meant by 'pisses you off'.
Yes, and there is a cognitive overhead to think SQL queries both in Django ORM syntax and SQL and when should I switch between ORM syntax and raw_sql, when should I implement custom manager etc.
Our codebase is an enterprise app and it has maybe a ratio of 50/50 between complex queries and straightforward single table selects or simple joins. I much prefer SQLAlchemy Core: I can think a complex query in SQL, try it in sql shell and implement it in SQLAlchemy Core so that the resulting code resembles the actual query. This resemblance also helps a lot of when you do performance optimizations.
I've been working on a small side project the past week or so using the 1.5 RC and following along the best practices recommended by 2 Scoops of Django -- https://django.2scoops.org
If you haven't already, I highly, highly recommend picking up the 2 Scoops book. It's got some great, proscriptive advice and is an easy-to-follow roadmap that helps answer a lot of "what is the right way to do this?" kinds of questions. Setting up your settings files for multiple environments, using CBV's, understanding the new User Model features, writing tests, recommended 3rd party tools, securing your setup -- these things are all a lot more clear to me.
And it's actually really well written, not just a bunch of recipes. Their explanation of mixins, for instance, is one of the clearest, most concise I've ever come across. Well worth $12 and a few hours of time to read through it.
Thanks for posting about this book, I've been meaning to get into Django for a while, but I didn't find the official tutorial to be terribly enlightening beyond the basics.
Plus there's a whole heap of non-code related environment stuff which I want to have best practice for too.
If anyone knows of any other good first-up books / websites (are there any interactive tutorials Treehouse / Codecademy style?), please let me know.
Fair warning: 2 Scoops definitely assumes some familiarity with how Django works, specifically models, views, templates, and forms. It won't introduce these concepts to you but will help you use them better.
Thanks, I worked through the tutorial, so I know the basics I suppose. But I got to the end and wanted it to keep going, so I guess this book will come in handing for learning beyond the official tutorial.
If you're interested: I wrote an extended follow-up to the 1.4 tutorial that is a bit more real-world: using South for migrations, bootstrap templates, learning to use the forms library, adding popular apps like debug-toolbar and so on, writing annotation and aggregation queries, etc. See the "courseware" link at http://simeonfranklin.com/pro-django-class/
>Django 1.5 is the first Django release with support for Python 3 (specifically, Python 3.2 and newer).
That sentence is of course followed by caveats about Python 3 support being experimental at this stage, but all-in-all I think this is a sign that we are finally at the tipping point for Python 3 to start gaining mainstream usage.
Thank you Django community for moving the ball forward for everyone.
FYI, the "experimental" thing is a community thing, not really a technical judgement. Since this is our first Python 3 release, we want to have some space to make changes between 1.5 and 1.6 that we otherwise would avoid because of our strong backwards compatibility promise. The "experimental" label is about giving ourselves that room and not surprising users if there do have to be changes in the way Py3 support works between 1.5 and 1.6.
Technically, however, it's pretty rock-solid. I'll be launching a site built on Py3/1.5 is about two weeks, and aside from constantly forgetting to `print(...)` instead of `print ...` it's been surprisingly smooth sailing.
Have you found any of the third-party Django extensions to be catching up? I'm starting a new project and would love to just start with Python3, but there are a few packages I depend on: South, lxml, pytz, simplejson, requests, django-compressor, gunicorn, jinja2, twisted, txAMQP, and django-rest-framework (amongst some other utilities actually used for development).
It would sure be great to have a list of django sub-projects and their Python3 status.
Regardless, even if we start with Python2.7 and bump up to 3.3 in a few months, this is a great step!
* txAMQP probably can't get ported until twisted does.
* django-rest-framework has Python 3 support, I think it's fairly recent, but it works well.
This list is about typical of what I've found doing Django/Py3 work: many things are ported, a bunch more have good alternatives, and a few things are still missing.
Off the top of my head: lxml, pytz, simplejson (as json in the stdlib), requests and jinja2 work already. Twisted has someone working on Python 3 support. The others I don't know about.
honest question: my job is programming in python. I never had python 3 installed on a machine, being it personal, a server or a computer at work. I never felt the need to. any time I wonder why I'm not using it, I go back to the "what's new" page and I remember why. I mean, the biggest change is print not being a statement anymore? Improved UTF8 is neat, and being Italian I work with not ASCII chars all the day, but even in large projects this comes down to a couple of encodings. I mean, multi-line lambdas, optional static decorators, those would justify a jump in version and backwork incompatibility, but map returning an iterator and not a list? Meh, this is good for python 2.actual_version + 1.
> I mean, the biggest change is print not being a statement anymore?
The reasons to upgrade to Python 3 are both numerous and serious. If the only hit on your code base is to change "print this" to "print(this)", by all means upgrade. And most conversions are automated -- just run a script named "2to3":
Asking why one would want to move from Python 2 to Python 3 is like asking how much a boat costs -- if you have to ask, you can't afford the consequences. Here are some of the reasons:
A quote: "At the time of writing (July 4, 2010), the final 2.7 release is out, with a statement of extended support for this end-of-life release. The 2.x branch will see no new major releases after that. 3.x is under active development and has already seen stable releases, such as the recent 3.2. This means that all recent standard library improvements, for example, are only available in Python 3.x."
Of course the push to a new version is strong and a newer version of a product represents its future. I'm not debating this or stating that it is stupid to use the newer version, but when I see someone writing "about time!", I read it like "wow, so I can finally use Python 3 and all its game changing brand new features!", but I don't see anything new than, when programming in Python 2x, makes me think "oh, if only I had used Python 3 here!". For example, when I upgraded to .net 3.5 and I got Linq, I really felt the pain of not having it available when maintaing older code and I finally decided to migrate it all to 3.5 due to the real new features.
Python 3's improved handling of UTF-8 is by itself worth the upgrade. I've spent more time than I care to recall trying to get Python 2.x to handle Unicode correctly.
I only mention this because it's a visible change that's easy to explain in a few words. The more basic changes are mostly subtle and difficult to describe without direct experience.
> but I don't see anything new than, when programming in Python 2x, makes me think "oh, if only I had used Python 3 here!".
That's not a very sound basis for comparative evaluation. If you have only ever owned a horse, the advantages of owning a car might not be obvious. The horse can go places the car cannot, so the fact that the car gets to other places faster might be overlooked.
Having used Python 3 a bit, there are things I miss in Python 2. Like when I write something quickly and accidentally use integer division (In Py3, 1/2 == 0.5).
> Having used Python 3 a bit, there are things I miss in Python 2. Like when I write something quickly and accidentally use integer division (In Py3, 1/2 == 0.5).
That's been addressed -- in Python 3 there are now two kinds of division and two operator symbols:
>>> 100 / 9
11.11111111111111
>>> 100 // 9
11
But you have to remember to use the right symbol. :)
Sorry, I should have made that clearer. I know and like the division semantics in Python 3. It's when I go back to Python 2 that I get bitten by 1/2==0.
I know that I can use __future__ to sort that out, but when I'm writing something quickly, I often forget that until I work out why my code is misbehaving.
> Django 1.5 introduces support for a configurable User model. The basic Django User model is still around, of course, but now there's first-class support for specifying your own model and having Django's auth system make use of it.
I guess having it be a special User model is just part of the deal with Django's good out-of-the-box admin. I don't even remember how the various Rails plugins (ActiveAdmin, for example) generates the scaffolding needed for an authenticated user.
It's very easy to extend the existing user model rather than creating one from scratch. I had to do some unconventional auth stuff recently and I only extended auth.User slightly (and also wrote a slightly modified authentication backend).
This feature was something we'd hoped would be awesome; it's not. Going over the documentation shows there's some jaw-dropping nastiness you have to go through to make it work.
It's good that they're providing it, but I think the complexity is going to turn people off (I know I won't be using it unless it's simplified at some point in the future). User profiles have always been used for adding data to User models indirectly, and I think this is probably going to remain the best way to handle it for most uses.
Can you expand on the "jaw-dropping nastiness you have to go through to make it work"? Seems pretty straightforward, though I have not tried to actually use it yet.
It appears the database migration is the biggest hurdle, but I don't think there's a way around that. User profiles require a join and that can be suboptimal, which is why this is a useful addition. If you weren't running into problems before it's probably better to not change (though that's usually the case for working code).
I suspect this may be the nastiness that's being referred to; this is the use case that I was hoping would be made dead simple.
With previous versions of Django I generated a random hash for use as a dummy/unguessable username, required an email address in the RegistrationForm, customized the AuthenticationForm, created a custom email authentication backend, and monkey patched User with various helper methods.
In 1.5 it looks like the AuthenticationForm will adapt to the field defined in USERNAME_FIELD[1], but a lot of work is still required. Support for easily using email address as the username (or support for easily specifying the username field in general without requiring all the other boilerplate) would probably go a long way.
> there's some jaw-dropping nastiness you have to go through to make it work.
What "jaw-dropping nastinesses" are those, and why didn't you check and report them during the beta/rc phase since you were "hoping it would be awesome"?
I've been using custom User models for over a month, and I can tell you that using a profile model is far nastier.
Besides avoiding a join in the DB (or worse, a separate select), being able to override user model methods has been an incredible benefit to my projects.
Yeah I've been using them for about a month too and all I can say is, this is how it should have always been.
The docs give you a pretty good starting point for a fully functional user model, and jarcoal (above) outlines a simple method for migrating from old to new.
The lack of a configurable User model is the reason I had to abandon django on a couple of projects. I like the framework, but formerly User was tied tightly up and down the framework (contrib.auth most notably).
Oh yes, it's easy. I was just forgetting exactly (I haven't used it in awhile) what it built out for you upon that command and what opinionated pattern it might constrain you to.
Not very opinionated at all, your application controller must expose a method to authenticate a user, and another to get the current user (defaults to :current_user which works out-of-the-box with Devise). Both method names can be configured in the initializer that is generated on install from this template: https://github.com/gregbell/active_admin/blob/master/lib/gen...
I haven't used ActiveAdmin in a few months, but when I last did I was really impressed.
It's great to see the Django tutorial extended to cover testing[1] and writing reusable apps[2]. These days there are quite a few Django tutorials out there covering best practices etc. (which are very good) but I would still recommend the official Poll app tutorial to any beginner because of it's simplicity.
Unit testing Django applications has been a source of pain for me. Writing functional or acceptances is ok using Django test client, although many recommend using WebTest, which is nice but slow if you're going to write hundreds of them.
Sorry for the Off topic, but anybody have a good experience with Appengine+Google Cloud SQL+Django?? I am thinking as alternative to AWS but I dont know if it's going to give me so much problems with the integration. Also a bit worry about the price in comparation with AWS. Anyone experience in both world?
Have you looked into Rackspace Cloud? Full disclosure: I work at Rackspace, but I honestly believe that Cloud Servers + Cloud Database (hosted MySQL) at Rackspace is vastly superior choice for a reasonably large number of projects/products than AWS.
IMO, the perfect setup for most non-Facebook sized money-making web apps is nearly always dedicated SSD-powered database hardware connected to a cheap cloud of virtual boxes to serve requests. Spending engineering $$$ on scaling your data across unreliable virtual instances often is not a good idea.
Going all-dedicated, if you can afford it, is great for pretty good uptime at zero engineering cost. I recommend SoftLayer for this: they sell cheap and reliable dedicated servers connected to pretty good networks (just stay away from their older Dallas-based DCs, but DC5 is good).
This was my experience as well. I wish I had that month back.
I still have an app on GAE (the high availability version) mostly because I don't want to roll out my own HA Mongo DB. At some point it will become cost effective to do my own.
The other AWS plus: when my response time skyrockets, I can figure it out and fix it.
Was your data in the Appengine Datastore? I believe elicox was asking about using Google Cloud SQL, which I believe makes data export relatively easy (Cloud SQL is basically managed MySQL). New Django + Cloud SQL also runs basically "pure" Django, rather than the hacked-up djangoappengine of the past, so next to zero code should have to be changed in a move off AppEngine.
I recently made the switch from Datastore/djangoappengine to Cloud SQL, and it has been a far better experience.
I'm working on a codebase that we recently ported from GAE to AWS. We ran into lots of issues with GAE, mainly around:
* Exorbitant cost
* Obtuse ORM
* Random, unannounced/poorly reported downtime
I'm happy to elaborate, but I would stay as far away as possible from GAE. Our experience was terrible. I should note as a disclaimer that we did not use the high availability version.
While Cloud SQL and Appengine both do look expensive, I have to say the new integration is quite nice to work with. I had struggled in the past with djangoappengine, which let Django run on the weirdness of the Appengine Datastore, but now that I'm running basically "pure" Django on MySQL it's far smoother sailing. Much less setup than AWS and even easier/more straightforward than doing Django on Heroku in my opinion, but ymmv.
It really depends on your usecase. I've been hosting simple Django-based websites for clients (think 500-1000 uniques a day) for some years, and couldn't be happier really. There has not been a single issue, and the prices for that kind of volume is laughably low ($2-4 a week). I would NOT do django + appengine for anything complex however, since in my experience getting everything to work together without banging your head too much requires a fairly standard Django-app.
Last time I touched any of these sites other than to add security patches and the likes was 6 months ago, so it could be better/worse these days, YMMV.
So, I'll ask the noob question that has previously been getting asked to death but there's finally new reason to ask once more: someone who's had little to no prior experience with Django, and still is very much a novice with Python -- do you suggest they start using Django with Python 3 or 2?
The Python 2 v 3 conundrum seems to have been going on for an eternity. It must be putting off new adopters in their droves. For a start, you have to make an important decision about which flavor to install and how to get started right at the beginning, with no canonical right answer to the dilemma. Do the great and the good in the Python community realize how damaging this is, and how such a thing should never ever be allowed to happen again ?
I have no idea what to do about 2 v 3 now. The grandparent is a genuine question, and my perspective is as a casual sometime Python user rather than a serious Python user. I am personally frustrated by the problem every time I'm tempted to get serious about Python. I'd love to know whether the key Python people acknowledge the problem in the way I've framed it and whether they have resolved to avoid something similar happening again in the future once this issue (finally) works itself out one way or another.
Python 3 support in Django 1.5 is experimental. I would wait until Django 1.6 is launched or there are well-known, well-working examples of Python 3 implementations of Django on high traffic sites.
FWIW, that "experimental" label doesn't quite mean that 1.5 isn't ready for prime-time; it's more about setting community expectations. Please see my reply elsewhere in this thread (https://news.ycombinator.com/item?id=5289006) for more details.
ETA: That said, the advice to stick to Py2 right now is probably good. There's still some key missing 3rd party packages, so you'll generally be happier as a Py2 user right now.
I have been running Django 1.5 on Python 3.3 since 1.5c1 - ran into zero problems. It is solid...
but... a lot of packages are not ready for 3 yet. So it depends how far you want to go.. Playing around by yourself? I'd go with Python 3... if you need to leverage a lot of the packages you'll need to drop down to 2.7
i'd say that if you want to learn python, go with 3. if you want to build something on third party libraries while learning python at the same time, start with 2.
I'm super excited about this release but I really, really envy the Russian Doll-caching through key-based expiration and the Turbolinks of the Rails 4 release. Man I really wish django would package all the JS magic Rails comes with.
It is highly unusual to use NoSQL as the main data store in Django (so much of the built-in functionality requires relational databases, so you end up net-negative). Most Django folks augment their relational database with some NoSQL bits.
We've been big fans of storing core data in Django models, but using things like key/value stores to store random extra bits that aren't exactly core to the model. Redis is great for this, or another model as triple store style GenericRelation if you need to query on it.
I don't imagine the nonrel branch will move again, its such a departure from core Django. Look into using Flask, as there aren't many "mature" frameworks that do NoSQL core.
I hate that movie. I've never seen it but now it's the first page of search about half the time when I'm googling development issues with the real Django :-)
Maybe it's Google Search biasing towards me (or at least my IP address), but Django, the framework, should be proud that it's keeping the top rank for that search term despite the buzz around Django, the movie (which, even though I love QT, was a pretty sloppy movie, IMO).
The real loser is Django Reindhardt, who Adrian Holovaty named the framework after, and is now bumped off the first page of Google results.
I get this feeling about Django, but not about Flask. Its codebase is so lean I can read all the relevant parts in an hour when I want to get back into it. I don't even need docs for this thing.
However, I understand what you mean about request / response, I don't like how this is handled in most python frameworks actually, it's usually too much abstracted away.
The nicest (imperative) environment for asynchronous execution I've seen is Objective C/Cocoa for some reason. It has a way of showing you all the handles you might need, but it also makes it fairly obvious when and how these handles are called. Together with lambda support ('blocks') it's simple but effective.
I think the main difference is enterprise + closed source + well documented environments vs. opensource + not so well documented environments often originating from someone's hobby. When it comes to big middleware frameworks I prefer the first, but small lean stuff such as Flask is just fine to use IMO.
My advice is to not rely too much on the docs when you want to really know something - take a look at the source, it's all there.
The django-firebird (fdb driver) is now available for installing via pypi. Just run: pip install django-firebird
https://pypi.python.org/pypi/django-firebird
It's developed for django 1.5+
Anecdotal: I wrote a Google Reader API library in Python 2 that I'm working on porting to Python 3 and it really hasn't been that bad. I had some HTTP dependancies on urllib/urllib2 but requests (with a py3 compatibility class) made it easy.
The port was requested by someone looking to build an RSS feed reader or checker in Sublime Text 3, which using Python 3.3. Things are moving forward.
On the Python 3 subject, I'd be highly interested in seeing if there any performance wins by switching your Django deployment to Python 3 over something like Python 2.7.
I hope this isn't too difficult to upgrade to from 1.4
Also, I'd like to thank all of the Django contributors for their excellent work and for making my job easier!
Django is still a cornerstone of our startup and we're way past the point where folks have traditionally said "Django starts to constraint you". We've found that to be untrue. We love the templating, the ORM and all the built-in tools (not to mention 100s of libraries that get you an 80% finished feature in 5% of the time).
I hope to meet a lot of you at Pycon, I'd be happy to buy you a beer. I'll be wearing the bright orange Zapier shirt, you can't miss me. :-)