Django 1.5 released
djangoproject.com
djangoproject.com
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. :-)
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'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.
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.
> perhaps your people just don't have much exposure > new, serious platforms
Both could have been omitted and your points would still have been valid.
Anyways, I'm not advocating Django as "the one true way", just stating that is hasn't hindered us in the least. :shrugs:
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).
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.
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.
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.
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.
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.
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).
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.
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.
A few specific things I like about Django:
1. A decent app ecosystem
2. Lots of documentation and a fairly mature codebase.
3. Django south for migrations.
Let me just say having migrations is a "good thing".
I know one place that just does SQL stuff by hand when they go to production. Seriously?!
Since that happened, I fricking love South.
1. What is "a decent app ecosystem"? We call these "libraries" elsewhere.
2. Pyramid same. (and, as someone whose attempted to build apps with both, I find Pyramid's much clearer)
3. This is ORM specific, not framework specific. SQLAlchemy has sqlalchemy-migrate or Alembic.
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.
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.
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.
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
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".
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.
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.
You can use Django with Jinja2 and SQLAlchemy.
There are problems Django solves and problems Pyramid solves and there I nothing wrong in using one or the other.
That's why I use Django.
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.
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".
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.
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).
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.
If anyone knows of any other good first-up books / websites (are there any interactive tutorials Treehouse / Codecademy style?), please let me know.
The official Django Tutorial is still a great starting place for getting your head wrapped around that stuff -- https://docs.djangoproject.com/en/dev/intro/tutorial01/
I'm also going to check out http://gettingstartedwithdjango.com
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.
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.
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!
* South doesn't have Py3 support in core, but there's a fork that does and seems to work perfectly: https://bitbucket.org/aaugustin/south-python3
* lxml as of v3 seems to have py3 support (I haven't tried it, but looks like it does).
* simplejson is now in the standard library as "json", so yes there.
* requests works, since v0.10 (about a year ago).
* django-compressor is not ported; however, django-pipeline does run on Python 3 and is basically -compressor's successor. It works great.
* gunicorn works on py3 (as does uwsgi and mod_wsgi, btw.)
* jinja2 hasn't been ported yet.
* twisted is actively being ported right now, and has gotten to the point of "kinda working". You can follow along at http://twistedmatrix.com/trac/milestone/Python-3.x and http://twistedmatrix.com/trac/wiki/Plan/Python3.
* 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.
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":
http://docs.python.org/2/library/2to3.html
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:
http://wiki.python.org/moin/Python2orPython3
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."
A more complete list of the changes:
http://docs.python.org/3/whatsnew/3.0.html
Bottom line -- if you don't migrate to Python 3, over time the corner you're painting yourself into will become smaller and smaller.
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.
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
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.
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).
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.
https://docs.djangoproject.com/en/1.5/topics/auth/customizin...
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).
1) Setup custom user model to inherit from AbstractUser with no additional fields.
2) Meta.db_table = 'auth_user' on custom user model
3) schemamigration --auto
4) migrate --fake (alternatively comment out statements in migration file and run without fake)
Now you can add new fields or change the inheritance to AbstractBaseUser and south will follow along.
I just wanted to add one field to the user model, but to do that I had to add 100+ lines of code.
I am very happy custom User models are possible now––but for most stuff I'll probably keep using a UserProfile.
[I'm a Django committer, FWIW.]
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.
[1] https://docs.djangoproject.com/en/dev/topics/auth/customizin...
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"?
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.
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.
Maybe this would be a nice way to contribute to Django...
> rails generate active_admin:resource [MyModelName]
I haven't used ActiveAdmin in a few months, but when I last did I was really impressed.
https://docs.djangoproject.com/en/dev/ref/templates/builtins...
[1]: https://docs.djangoproject.com/en/1.5/intro/tutorial05/
[2]: https://docs.djangoproject.com/en/1.5/intro/reusable-apps/
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).
Reasons:
Local development with Appengine is pretty bad. Good luck debugging and profiling production issues.
Appengine will make you jump through many hoops that undermine or completely drop pieces of the Django framework.
Getting data out of Appengine is a huge nightmare and timesink.
If you ever decide to migrate off Appengine you will need to rewrite almost everything.
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.
I recently made the switch from Datastore/djangoappengine to Cloud SQL, and it has been a far better experience.
(where I work)
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.
Docs on running native django on cloud sql: https://developers.google.com/appengine/docs/python/cloud-sq...
A guide I used to set it up: http://www.joemartaganna.com/web-development/running-django-...
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.
I really, really wanted to say to you Python 3, because:
- It is better (it fixes some annoyances)
- Django is working really great with it
But some things (that Django uses, but are not Django) are not working yet. Things like MySQL adaptors, South, etc
Or maybe go with Python 3 and wait for the issues to be fixed, they probably will, soon enough
There are ways to write software that's compatible with both Python 2 and 3 (using six for example: http://pythonhosted.org/six/)
But I guess it's mostly developers not having the time to update (it's easier if you kept it updated and not using some old constructs)
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'm really looking forward to migrating a few projects up to Python 3 and Django 1.5. It's going to be awesome!
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
Plus, 2 is not going away in near future, and you'll be able to pick up 3 easily after that
What framework do other people using NoSQL data stores use?
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.
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 am getting turned off left right and centre by frameworks - Django and even Flask just make reasoning about the request/response more difficult.
Maybe I don't know how to use this but ... It would take me three months to read the new Django docs.
I am not a hater here, just wanting the simple life
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 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.
* If you use decimal module, you will benefit from the serious speed improvements (http://docs.python.org/dev/whatsnew/3.3#decimal).
* The memory usage of strings is slightly lower (http://docs.python.org/3/whatsnew/3.3#performance-and-resour...).
#django on FreeNode is pretty good, though.