Upgrade to Pro — share decks privately, control downloads, hide ads and more …

Django: The Good Parts by James Bennett

D21717ea76044d31115c573d368e6ff4?s=47 PyCon 2014
April 12, 2014
1.3k

Django: The Good Parts by James Bennett

D21717ea76044d31115c573d368e6ff4?s=128

PyCon 2014

April 12, 2014
Tweet

Transcript

  1. django (the good parts) James Bennett • PyCon Montréal •

    April 12, 2014
  2. Initial public preview: July 2005

  3. Nearly nine years later…

  4. Django 1.7 beta 1: 161,923 lines of Python

  5. Full stack • Request/response • Templating • ORM • Forms

    library • Auth • Admin • Security (XSS/CSRF/ clickjacking) • Testing framework • Caching framework • Logging framework • etc., etc.
  6. Now the literal 800lb. gorilla

  7. Aren’t other frameworks smaller/lighter and thus better?

  8. The good parts • HTTP abstraction + request/response cycle •

    Conservative (yes!) approach to features • The secret weapon: apps
  9. HTTP sucks

  10. H(ate)TTP • Nine different request methods, some safe, some idempotent,

    some neither, vastly different request/response characteristics • Unicode-unaware • Persistence, auth, streaming, security all tacked on/afterthoughts
  11. CGI isn’t much fun, either

  12. How to CGI • Script invoked by web server, request

    information stored in environment variables • Submitted data received via standard input • Script does its processing • Response headers and response body sent via standard output
  13. How to (actually) CGI • Script invoked by web server,

    you hope, if everything’s configured correctly • chmod 777 ALL the things! • Environment is full of lies and sadness • Give up figuring out what the actual requested URL was and fork()-bomb the server • Drink. A lot.
  14. WSGI is basically CGI with a bit of Python

  15. Having a standard is good, but…

  16. WSGI pain points • CGI-style environ: have to pass it

    around, parse it, re-parse it, re-re-parse it, re-re-re-parse it… • Signaling up and down the stack requires inventing ad-hoc protocols • Return/response API sucks. For reals. • Inherits HTTP’s awful approach to character encoding
  17. We can do better than this

  18. Let’s do better! • HTTPRequest • Already parsed and normalized

    for you • Sensible attribute and dictionary-based access • Relatively sane handling of character encoding
  19. Let’s do better! • HttpResponse • Easy to construct and

    manipulate • Convenient subclasses for common specialized responses (404, redirects, etc.)
  20. Let’s do better! • Write a callable that takes an

    HttpRequest as argument, and either returns an HttpResponse or raises an exception • URL parsing done for you: map regexes (URLs) to callables • Want extra arguments? Put capturing groups in the regex
  21. That’s it. That’s HTTP.

  22. But wait, there’s more!

  23. Life cycle • Middleware system baked in (all middleware systems

    suck, though) • Signals! • Decorators! • Call other stuff — it’s callables all the way down
  24. We read PEP 333 so you don’t have to •

    A Django project is a WSGI application • wsgi.py + WSGI_APPLICATION setting • Translate WSGI environ to HttpRequest • Translate returned HTTPResponse to WSGI response format
  25. Sane HTTP/WSGI is worth importing some stuff

  26. Compassionate conservatism

  27. Nobody’s ever going to call it minimal

  28. The truncatechars filter (was new in 1.4)

  29. That only took four years

  30. Migrations (coming in 1.7)

  31. Only took about six years

  32. Things get into Django slowly

  33. Now they’re getting out

  34. Unbundling/removing • contrib.comments • contrib.databrowse • contrib.localflavor • contrib.markup •

    Probably more to come
  35. Things are difficult to add, easier to remove

  36. This is usually described as a bad thing

  37. (not necessarily)

  38. Conservatism • Strong preference for community solutions • Core framework

    more about providing API support • More “swappable” components than expected
  39. Conservatism • More stability over time • Features land when

    ready • Competition often produces better solutions
  40. Encapsulation

  41. Enc-app-sulation

  42. A Django project is a WSGI application

  43. What is a Django application?

  44. Monoliths and black boxes and problems

  45. Maybe: • Some models • Some views • Some forms

    • Some utility code • Some middleware • etc.
  46. Safe assumptions and safer integration

  47. Django applications are encapsulated, pluggable functionality

  48. Do one thing and do it well

  49. My personal site: 12 apps

  50. MDN: closer to 50

  51. (about a dozen are MDN- specific)

  52. django-packages lists 2,206 available apps

  53. Apps are a secret weapon

  54. Questions?