In July I deployed a major update to dpaste.com. Nothing exploded. Good things resulted. The TLDR It looks different of course, but here’s the other stuff that’s new: Proper user accounts replaced the old cookie-based “accounts” Signup via GitHub, GitLab, Bitbucket, Google, or plain ol’ username/password “Favorites” feature Optional public profile (linked from items you post) Responsive HTML layouts (looks good on your phone now!) 100% HTTPS More robust database setup Application hosting by PythonAnywhere Lengthened the base-32 item IDs from 7 to 9 digits (and dropped the ambiguous 0, 1, O, I) Added a latest-item blurb (with geolocation when available) to the About page, for fun.
TLDR: Use python-future. The Project Last summer I led the conversion of a 100KLOC Python 2 web application to Python 3. The application is called “Accelerate” - the backbone of operations at my employer, MassChallenge, a global startup accelerator. It handles every stage of a running accelerator program: account creation for entrepreneurs and experts (mentors) startup applications online and in-person judging of applications coordination of one-on-one meetings with mentors during the program generation of reports used by judges selecting cash award recipients So, it’s a mission-critical app.
(Note: This is a writeup I did a few years ago when evaluating Riak KV as a possible data store for a high-traffic CMS. At the time, the product was called simply “Riak”. Apologies for anything else that has become out of date that I missed. Also please pardon the stiff tone! My audience included execs who we wanted to convince to finance our mad scientist data architecture ideas.) Riak is a horizontally scalable, fault-tolerant, distributed, key/value store.
Eight years ago, I launched a simple pastebin site written in Django. In those early Django days I spent a lot of time in the #django IRC channel. I thought we should have a pastebin that knew how to correctly colorize our code, and which was written in our framework to boot. So I wrote one. Eventually its URL ended up in the channel topic, then in the Django source code itself.
A significant difference between developing Django sites versus static-HTML-based approaches (among which I count PHP and the like) is that static files, aka “media”, live in a dedicated spot. Sometimes you need a piece of static content to be available at a specific URL outside your media root. robots.txt for example. This can be done in pure Django (i.e. without even touching your Apache configuration), and is especially nice if your robots.
If you use Django’s admin application, you’re familiar with its “Recent Actions” sidebar. It gives a simple summary of your latest edits, including clickable links to the relevant objects (not any ones you deleted, naturally, but ones you added or changed). It’s probably not something you look at very often, unless you do such intensive work in the admin that you lose track of things. Django stores that log data (via the admin’s LogEntry model) for all admin users, a fact which has caused me to repeatedly daydream about writing a custom view or two to display it.
“I’m a PHP programmer and I want to check out this Django thing. What should I do?” I’ve been seeing this kind of question pop up more and more, and I have a few answers. First-hand experience as well as many conversations with developers online have led me to the same conclusion: the curious person behind such a question should be encouraged and assisted. (I’ll call that person “Pat” for the rest of the post, for convenience and conscientious gender-neutrality.