Category Archives: Django

[repost ]Website Monitoring with Distributed Messages/Tasks Processing (AMQP & RabbitMQ) on Django



[repost ]Python and Django on Heroku


Python has joined the growing ranks of officially-supported languages on Heroku’s polyglot platform, going into public beta as of today. Python is the most-requested language for Heroku, and it brings with it the top-notch Django web framework.

As a language, Python has much in common with Ruby, Heroku’s origin language. But the Python community has its own unique character. Python has a culture which finds an ideal balance between fast-moving innovation and diligent caution. It emphasizes readability, minimizes “magic,” treats documentation as a first-class concern, and has a traditon of well-tested, backward-compatible releases in both the core language and its ecosystem of libraries. It blends approachability for beginners with maintainability for large projects, which has enabled its presence in fields as diverse as scientific computing, video games, systems automation, and the web.

Let’s take it for a spin on Heroku.

Heroku/Python Quickstart

Make a directory with three files:

import os from flask import Flask app = Flask(__name__) @app.route("/") def hello(): return "Hello from Python!" if __name__ == "__main__": port = int(os.environ.get("PORT", 5000))'', port=port) 




web: python 

Commit to Git:

$ git init $ git add . $ git commit -m "init" 

Create an app on the Cedar stack and deploy:

$ heroku create --stack cedar Creating young-fire-2556... done, stack is cedar | Git remote heroku added $ git push heroku master Counting objects: 5, done. Delta compression using up to 4 threads. Compressing objects: 100% (3/3), done. Writing objects: 100% (5/5), 495 bytes, done. Total 5 (delta 0), reused 0 (delta 0) -----> Heroku receiving push -----> Python app detected -----> Preparing virtualenv version 1.6.1 New python executable in ./bin/python2.7 Also creating executable in ./bin/python Installing setuptools............done. Installing pip...............done. -----> Installing dependencies using pip version 1.0.1 Downloading/unpacking Flask==0.7.2 (from -r requirements.txt (line 1)) ... Successfully installed Flask Werkzeug Jinja2 Cleaning up... -----> Discovering process types Procfile declares types -> web -----> Compiled slug size is 3.5MB -----> Launching... done, v2 deployed to Heroku To * [new branch] master -> master 

Then view your app on the web!

$ curl Hello from Python! 

Dev CenterGetting Started with Python on Heroku/Cedar

All About Python

Created by Guido van Rossum in 1991, Python is one of the world’s most popular programming languages, and finds application in a broad range of uses.

Cutting-edge communities, like Node.js and Ruby, encourage fast-paced innovation (though sometimes at the cost of application breakage). Conservative communities, like Java, favor a more responsible and predictable approach (though sometimes at the expense of being behind the curve). Python has managed to gracefully navigate a middle path between these extremes, giving it a respected reputation even among non-Python programmers. The Python community is an island of calm in the stormy seas of the programming world.

Python is known for its clearly-stated values, outlined in PEP 20, The Zen of Python. “Explicit is better than implicit” is one example (and a counterpoint to “Convention over configuration” espoused by Rails). “There’s only one way to do it” is another (counterpointing “There’s more than one way to do it” from Perl). SeeCode Like a Pythonista: Idiomatic Python for more.

The Python Enhancement Proposal (PEP) brings a structured approach to extending the core language design over time. It captures much of the value of Internet standard bodies procedures (like Internet Society RFCs or W3C standards proposals) without being as heavy-weight or resistant to change. Again, Python finds a graceful middle path: neither changing unexpectedly at the whim of its lead developers, nor unable to adapt to a changing world due to too many approval committees.

Documentation is one of Python’s strongest areas, and especially notable because docs are often a second-class citizen in other programming languages. Read the Docs is an entire site dedicated to packaging and documentation, sponsored by the Python Software Foundation. And the Django book defined a whole new approach to web-based publishing of technical books, imitated by many since its release.

Frameworks and the Web

In some ways, Python was the birthplace of modern web frameworks, with Zope and Plone. Concepts like separation of business and display logic via view templating, ORMs for database interaction, and test-driven development were built into Zope half a decade before Rails was born. Zope never had the impact achieved by the later generation of frameworks, partially due to its excessive complexity and steep learning curve, and partially due to simply being ahead of its time. Nevertheless, modern web frameworks owe much to Zope’s pioneering work.

The legacy of Zope’s checkered history combined with the Python community’s slow recognition of the importance of the web could have been a major obstacle to the language’s ongoing relevance with modern developers, who increasingly wanted to build apps for the web. But in 2005, the Django framework emerged as a Pythonic answer to Rails. (Eventually, even Guido came around.)

Django discarded the legacy of past Python web implementations, creating an approachable framework designed for rapid application development. Django’s spirit is perhaps best summarized by its delightful slogan: “the web framework for perfectionists with deadlines.” Where Rails specializes on CRUD applications, Django is best known for its CMS capabilities. It has an emphasis on DRY (Don’t Repeat Yourself). The Django community prefers to create reusable components or contribute back to existing projects over single-use libraries, which helps push the greater Python community forward. While Django is a batteries-included framework, the loose coupling of components allows flexibility and choice.

Other frameworks have found traction as well. Flask, a Sinatra-like microframework, makes use of Python’s decorators for readability. Pyramid emerged from the earlier Pylons and TurboGears projects, and their documentation already offers excellent instructions for deploying to Heroku.

Similarly, Python established a pattern for webserver adapters with WSGI. Many other languages have since followed suit, such as Rack for Ruby, Ring for Clojure, and PSGI/Plack for Perl.

In the Wild

Perhaps most striking about Python is the breadth of different realms it has taken root in. A few examples:

  • Science and math computing, evidenced by books and the SciPy libraries and conferences.
  • Video games, as seen in libraries such as PyGame and Cocos2d.
  • As an embedded scripting / extension language, in software such as Blender3DCivilization IV, andEVE Online (via Stackless Python).
  • Major Linux distributions use Python for their system tools, such as yum and the Red Hat Network client for Red Hat and Fedora; or almost all of the GUI configuration and control panels on Ubuntu.
  • It’s one of the three official languages used by Google, alongside Java and C++.
  • And of course, internet startups: Reddit, Youtube, Disqus, Dropbox, and countless others use Python to build their businesses.


We anticipate that Python will be one of the most-used languages on the Heroku platform, and are overjoyed to welcome our Python brothers and sisters into the fold.

Special thanks to all the members of the Python community that helped with alpha testing, feedback, and patches on Heroku’s Python support, including: David CramerBen BangertKenneth LoveArmin Ronacher, and Jesse Noller.

We’ll be sponsoring and speaking at PyCodeConf next week. Come chat with us about what you’d like to see out of Python on Heroku!

Further reading:

Django 1.3 release 推迟

本应该1约31日,Django 发布1。3的release.


With these factors in mind, we have revised the release schedule: we are now aiming to produce a release candidate in the week of February 14, with a final release in the week of February 21.


Django 1.3 release notes

What’s new in Django 1.3

Class-based views

Django 1.3 adds a framework that allows you to use a class as a view. This means you can compose a view out of a collection of methods that can be subclassed and overridden to provide common views of data without having to write too much code.

Analogs of all the old function-based generic views have been provided, along with a completely generic view base class that can be used as the basis for reusable applications that can be easily extended.

See the documentation on Class-based Generic Views for more details. There is also a document to help you convert your function-based generic views to class-based views.


Django 1.3 adds framework-level support for Python’s logging module. This means you can now easily configure and control logging as part of your Django project. A number of logging handlers and logging calls have been added to Django’s own code as well – most notably, the error emails sent on a HTTP 500 server error are now handled as a logging activity. See the documentation on Django’s logging interface for more details.

Extended static files handling

Django 1.3 ships with a new contrib app 'django.contrib.staticfiles' to help developers handle the static media files (images, CSS, Javascript, etc.) that are needed to render a complete web page.

In previous versions of Django, it was common to place static assets in MEDIA_ROOT along with user-uploaded files, and serve them both at MEDIA_URL. Part of the purpose of introducing the staticfiles app is to make it easier to keep static files separate from user-uploaded files. For this reason, you will probably want to make your MEDIA_ROOT and MEDIA_URL different from your STATIC_ROOT and STATIC_URL. You will need to arrange for serving of files in MEDIA_ROOT yourself; staticfiles does not deal with user-uploaded media at all.

See the reference documentation of the app for more details or learn how to manage static files.

unittest2 support

Python 2.7 introduced some major changes to the unittest library, adding some extremely useful features. To ensure that every Django project can benefit from these new features, Django ships with a copy of unittest2, a copy of the Python 2.7 unittest library, backported for Python 2.4 compatibility.

To access this library, Django provides the django.utils.unittest module alias. If you are using Python 2.7, or you have installed unittest2 locally, Django will map the alias to the installed version of the unittest library. Otherwise, Django will use it’s own bundled version of unittest2.

To use this alias, simply use:

from django.utils import unittest

wherever you would have historically used:

import unittest

If you want to continue to use the base unittest libary, you can — you just won’t get any of the nice new unittest2 features.

Transaction context managers

Users of Python 2.5 and above may now use transaction management functions as context managers. For example:

with transaction.autocommit():
    # ...

For more information, see Controlling transaction management in views.

Configurable delete-cascade

ForeignKey and OneToOneField now accept an on_delete argument to customize behavior when the referenced object is deleted. Previously, deletes were always cascaded; available alternatives now include set null, set default, set to any value, protect, or do nothing.

For more information, see the on_delete documentation.

Contextual markers and comments for translatable strings

For translation strings with ambiguous meaning, you can now use the pgettext function to specify the context of the string.

And if you just want to add some information for translators, you can also add special translator comments in the source.

For more information, see Contextual markers and Comments for translators.


It can sometimes be beneficial to allow decorators or middleware to modify a response after it has been constructed by the view. For example, you may want to change the template that is used, or put additional data into the context.

However, you can’t (easily) modify the content of a basic HttpResponse after it has been constructed. To overcome this limitation, Django 1.3 adds a new TemplateResponse class. Unlike basic HttpResponse objects, TemplateResponse objects retain the details of the template and context that was provided by the view to compute the response. The final output of the response is not computed until it is needed, later in the response process.

For more details, see the documentation on the TemplateResponse class.

Caching changes

Django 1.3 sees the introduction of several improvements to the Django’s caching infrastructure.

Firstly, Django now supports multiple named caches. In the same way that Django 1.2 introduced support for multiple database connections, Django 1.3 allows you to use the new CACHES setting to define multiple named cache connections.

Secondly, Versioningsite-wide prefixing and transformation has been added to the cache API.

Lastly, support for pylibmc has been added to the memcached cache backend.

For more details, see the documentation on caching in Django.

Permissions for inactive users

If you provide a custom auth backend with supports_inactive_user set to True, an inactive user model will check the backend for permissions. This is useful for further centralizing the permission handling. See the authentication docs for more details.


The GeoDjango test suite is now included when running the Django test suite with when using spatial database backends.


Previously, the MEDIA_URL setting only required a trailing slash if it contained a suffix beyond the domain name.

A trailing slash is now required for MEDIA_URL and the new STATIC_URL setting as long as it is not blank. This ensures there is a consistent way to combine paths in templates.

Project settings which provide either of both settings without a trailing slash will now raise a PendingDeprecation warning.

In Django 1.4 this same condition will raise an ImproperlyConfigured exception.

Everything else

Django 1.1 and 1.2 added lots of big ticket items to Django, like multiple-database support, model validation, and a session-based messages framework. However, this focus on big features came at the cost of lots of smaller features.

To compensate for this, the focus of the Django 1.3 development process has been on adding lots of smaller, long standing feature requests. These include:

  • Improved tools for accessing and manipulating the current Site.
  • RequestFactory for mocking requests in tests.
  • A new test assertion — assertNumQueries() — making it easier to test the database activity associated with a view.
  • Support for lookups spanning relations in admin’s list_filter.
  • Support for _HTTPOnly cookies.
  • mail_admins() and mail_managers() now support easily attaching HTML content to messages.
  • EmailMessage now supports CC’s.
  • Error emails now include more of the detail and formatting of the debug server error page.
  • simple_tag() now accepts a takes_context argument, making it easier to write simple template tags that require access to template context.
  • A new render() shortcut — an alternative to render_to_response() providing a RequestContext by default.
  • Support for combining F() expressions with timedelta values when retrieving or updating database values.


Python Django slide resource

Django In Depth

Introduction to Django

Pinax Tutorial 09/09/09

You’ve done the Django Tutorial, what next?

Django for Beginners

[repost]Lessons from Pownce – The Early Years


Lessons from Pownce – The Early Years

Pownce is a new social messaging application competing micromessage to micromessage with the likes of Twitter and Jaiku. Still in closed beta, Pownce has generously shared some of what they’ve learned so far. Like going to a barrel tasting of a young wine and then tasting the same wine after some aging, I think what will be really interesting is to follow Pownce and compare the Pownce of today with the Pownce of tomorrow, after a few years spent in the barrel. What lessons lie in wait for Pownce as they grow?


Information Sources

  • Pownce Lessons Learned – FOWA 2007
  • Scoble on Twitter vs Pownce
  • Founder Leah Culver’s Blog

    The Platform

  • Python
  • Django for the website framework
  • Amazon’s S3 for file storage.
  • Adobe AIR (Adobe Integrated Runtime) for desktop application
  • Memcached
  • Available on Facebook
  • Timeplot for charts and graphs.

    The Stats

  • Developed in 4 months and went to an invite-only launch in June.
  • Began as Leah’s hobby project and then it snowballed into a real horse with the addition of Digg’s Daniel Burka and Kevin Rose.
  • Small 4 person team with one website developer.
  • Self funded.
  • One MySQL database.
  • Features include:
    – Short messaging, invites for events, links, file sharing (you can attach mp3s to messages, for example).
    – You can limit usage to a specific subset of friends and friends can be grouped in sets. So you can send your mp3 to a specific group of friends.
    – It does not have an SMS gateway, IM gateway, or an API.

    The Architecture

  • Chose Django because it had an active community, good documentation, good readability, it is open to growth, and auto generated administration.
  • Chose S3 because it minimized maintenance and was inexpensive. It has been reliable for them.
  • Chose AIR because it had a lot of good buzz, ease of development, creates a nice UI, and is cross platform.
  • Database has been the main bottleneck. Attack and fix slow queries.
  • Static pages, objects, and lists are cached using memcached.
  • Queuing is used to defer more complex work, like sending notes, until later.
  • Use pagination and a good UI to limit the amount of work performed.
  • Good indexing helped improve the performance for friend searching.
  • In a social site:
    – Make it easy to create and destroy relationships.
    – Friend relationships are the most important information to display correctly because people really care about it.
    – Friends in the online world have real-world effects.
  • Features are “biased” for scalability
    – You must get an invite from someone on already on Pownce.
    – Invites are limited to their data center’s ability to keep up with the added load. Blindly uploading address books can bring on new users exponentially. Limiting that unnatural growth is a good idea.
  • Their feature set will expand but they aren’t ready to commit to an API yet.
  • Revenue model: ads between posts.

    Lessons Learned

  • The four big lessons they’ve experienced so far are:
    – Think about technology choices.
    – Do a lot with a little.
    – Be kind to your database.
    – Expect anything.
  • Have a small dedicated team where people handle multiple jobs.
  • Use open source. There’s lots of it, it’s free, and there’s a lot of good help.
  • Use your resources. Learn from website doc, use IRC, network, participate in communities and knowledge exchange.
  • Shed work off the database by making sure that complex features are really needed before implementing them.
  • Cultivate a prepared mind. Expect the unexpected and respond quickly to the inevitable problems.
  • Use version control and make backups.
  • Maintain a lot of performance related stats.
  • Don’t promise users a deadline because you just might not make it.
  • Commune with your community. I especially like this one and I wish it was done more often. I hope this attitude can survive growth.
    – Let them know what you are working on and about new features and bug fixes.
    – Respond personally to individual bug creators.
  • Take a look at your framework’s automatically generated queries. They might suck.
  • A sexy UI and a good buzz marketing campaign can get you a lot of users.

    Related Articles

  • Scaling Twitter: Making Twitter 10000 Percent Faster.