Warning: default was False previously so this example is backwards
Think about this code:
class Missile(models.Model):
# we can only attack short countries
target = models.CharField(max_length=7)
should_launch = models.BooleanField()
def launch(self):
"""
pass launches the missile
"""
pass
You recently added a new missile:
# add new missile in case we have to attack Merica
# it won't be launched until we set should_launch to True
Missile.objects.create(target="Merica")
Then you have a view:
/missile/launch_missiles
with the code:
for missile in Missile.objects.filter(should_launch=True):
missile.launch()
You'll have the unexpected behavior of launching that missile you just added.
With the new behavior your missile wouldn't be launched until you told it to. Basically this update has everything to do with the missile above failing this conditional:
missile.should_launch is True
Since 'None is not True and None is not False', it is a sensible default for Booleans.
One not only is the example backwards, but given the previous behavior, the correct thing would have occurred. This is a complete nitpick but whatever.
More importantly, this shows a lack of understanding about the framework being used, not an issue with the framework. The example has a programmer basically assuming the default is False when it was True, or more correctly that the default was not True. That is an issue with the programmer (and testing) not with the framework, unless it was undocumented. Django is documented quite well. The programmer here assumed something worked one way that was clearly documented to work the other.
Booleans defaulting to False is not unusual, but not universal either. Django has chosen to go the path of explicitness, which is a fine choice to make, as opposed to defaulting to False which is often considered to be a safe choice. I don't see a problem with not assigning a default, but I also don't see a problem with the default being False.
Defaulting to NULL could cause other problems, at least for the programmer above who didn't read documentation and worked on assumption.
Things should make sense without reading documentation (I'm not saying that you don't need to read it) and boolean having a default doesn't make any sense. Argument about it having a default value in other frameworks isn't a real argument either.
I don't see the problem.