Django: The Good Parts by James Bennett

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?