Conventions, not Rules
As many newcomers to Python discover, a lot of things they've lived with as
rules in other languages [such as public/private members] ... and,
conversely, some things they're accustomed to as conventions are now rules
Now, Django continues its history of embracing Pythonic ideals when it comes to
filenames. Many frameworks are very strict about what goes where ... in almost
all cases, Django couldn't care less.
Note: This post is still a Work In Progress.
I am posting it now to help people with what I have, and seek feedback and
Recently a few people have been asking about managing dynamic numbers of
When we look at how Admin handles inlines we see Django can handle this
So, 4 years ago [already??] I wrote a post about a shortcut to getting "User
registration with verification email", using very little code by leveraging the
password reset machinery built into Django.
Since then, of course, Django has moved on... and recently, the auth views were
rewritten as class-based views, which changes the game entirely.
As a result, I've committed to providing here an updated version of the
Every so often (quite frequently, actually) you'll get someone in #django
begging for help trying to integrate some app that promises the world ... at
least, as far as it concerns user registration and profiles.
A couple of people pointed out the original version would end up requiring the user to enter their email twice.
I've now amended the code so the password_reset view's work is now done in the registration CreateView.
This makes the view a little more complicated, but the URLs and user workflow much simpler.
The thing is, now that we have custom User models, doing this is easier than
ever before - yes, even including email verification.
So, I saw a post recently about Build an API under 30 lines of
I started wondering what it would take to do the same in Django.
The two main tools we're going go use are
This comes up a lot in #django ... and the solution is [as many are with
Django] much simpler than people assume.
Frequently I see people reach for formsets, in the mistaken conclusion that
formsets are for operating on related models. The sad part is that formsets
rely on the same functionality that the proper solution relies on, but the
seeker does not see it.
Somewhere people get the idea that for a single <form> submission, they
can only use a single Form class... but the formset should show that that's not
true; it uses multiple forms from the one submission.