Amir Rachum

Grave Injustice

Now, this isn't to say we're building a bad product, or that it doesn't work. My problem is that it has very rough edges regarding user experience and we almost never get around to fixing these issues. Sure, if there are bugs in functionality we usually solve them first, but there is a class of "comfort" problems which aren't really bugs and we have a lot of them.

This is partly because the backend and frontend are split between two different software groups. But I'm not blaming this on the frontend guys. The problem is the attitude that more features that are more-or-less stable are better than less features that are rock solid.

Now, I get that sometimes there are time-critical features that give value to the customer (this is a big phrase for us, as we work in Scrum), I do. But I realized that I work very differently at work from how I work at home. When I'm working on something at home and I see something that bothers me I usually fix it immediately (I, of course, finish what I'm currently working on first). At work, it's a completely different story. When I see an "injustice", I send an email to our product owner. He adds it to the backlog. We discuss it in meetings and prioritize it.

Whenever I "walk past" the bit of code that's responsible, I get upset. I want to fix it NOW! The existence of this issue is like a thorn in my side. I hate it.

The Heart Wants What the Heart Wants

I feel it's like technical debt, but it's not exactly the same. These issues are bugs to me, but our product owner doesn't see them this way.

I don't really know how to deal with being bummed out about this. I'd appreciate opinions from other developers who experience similar feelings. How do you settle the need for setting and discussing issues and priorities with your need to fix things as you see them? How do you deal with getting others to feel the same? If you practice Scrum, I would very much like to hear your methods and ideas.

Different Ways to Import

import foo

The basic Python import. The statement import foo looks for a foo model, loads it into memory and creates a module object called foo. How does Python knows where to find the foo module?

When a module named spam is imported, the interpreter first searches for a built-in module with that name. If not found, it then searches for a file named spam.py in a list of directories given by the variable sys.path. sys.path is initialized from these locations:

the directory containing the input script (or the current directory).

PYTHONPATH (a list of directory names, with the same syntax as the shell variable PATH).

the installation-dependent default.

(from the documentation)

If there is a bar object (which could be anything from a function to a submodule) it can be accessed like a member: foo.bar. You can also import several modules in one line by doing import foo, bar, but it is considered good practice to put each import in a single line.

from foo import bar

This statement imports bar which could be anything that is declared in the module. It could be a function definition, a class (albeit a not-conventionally-named class) or even a submodule (which make foo a package). Notice that if bar is a submodule of foo, this statement acts as if we simply imported bar (if it was in Python's search path). This means that a bar object is created, and its type is 'module'. No foo object is created in this statement.

Multiple members of foo can be imported in the same line like so:

from foo import bar, baz

The meaning of this is pretty intuitive: it imports both bar and baz from the module foo. bar and baz aren't neccessarily the same types: baz could be a submodule and bar could be function, for that matter. Unlike importing unrelated modules, it's perfectly acceptable to import everything from one module in the same line.

from foo import *

Sometimes foo contains so many things, that it becomes cumbersome to import them manually. Instead, you can just import * to import them all at the same time.

Don't do this unless you know what you're doing!

It may seem convenient to just import * instead of specific members, but it is considered bad practice. The reason is that you are in fact "contaminating" your global namespace. Imagine that you do import * on a package where someone unwittingly declared the following function:

def list():     raise RuntimeError("I'm rubber, you're glue!")

When you do import *, this list definition will *override* the global, built-in list type and you'll get very, very unexpected errors.

So it's always better to know *exactly* what you're importing. If you're importing too much stuff from a certain package, you can either just suck it up or just import the package itself (import foo) and use the foo qualifier for every use.

An interesting good use for import * is in Django settings file hierarchy. It's convenient there because you actually do want to manipulate the global namespace with imported settings.

from foo import bar as fizz

This one is far less common than what we covered so far, but still well known. It acts like from foo import bar, except instead of creating a bar object, it creates a fizz module with the same meaning. There are two main reasons to use this kind of statement: the first is when you're importing two similarly named objects from two different modules. You then use import as to differentiate them, like so:

from xml import Parser as XmlParser from json import Parser as JsonParser

 The other reason, which I've seen used a few times is when you import a lone-named function (or class) and use it extensively throughout your code and want to shorten its name.

from .foo import bar

Well, this escalated quickly.

This one is pretty rare and a lot of people are completely unaware of it. The only difference in this statement is that it uses a modified search path for modules. Namely, instead of searching the entire PYTHONPATH, it searches in the directory where the importing file lives. So if you have two files called fizz.py and foo.py, you can use this import in fizz, and it will import the correct file, even if you have another foo module in your PYTHONPATH.

What is this good for? Well, sometime you create modules with generic names like common, but you might also have a common package in the base of your project. Instead of giving different names, you can explicitly import the one closest to you.

You can also use this method to load modules from an ancestor in the directory tree by putting several dots. For example, from ..foo import Foo will search one directory up, from ...foo import Foo will search two directories up, etc.

foo = __import__("foo")

Ever wondered how can you import a module dynamically? This is how. Obviously you wouldn't use it with an explicit string, but rather with a variable of some kind. Also notice that you have to explicitly assign the imported module to a variable, or you won't have access to its attributes.

reload(foo)

This statement does exactly what it looks like. It reloads the foo module. It's pretty useful when you have a console open playing with a bit of code you're tweaking and want to continue without resetting your interpreter.

Note: If you used from foo import bar, it's not enough to reload foo for bar to update. You need to both reload foo and call from foo import bar again.

Import Loops

An import loop would occur in Python if you import two or more modules in a cycle. For example, it in foo.py you would from bar import Bar and in bar.py you from foo import Foo, you will get an import loop:

Traceback (most recent call last):   File "foo.py", line 1, in <module>     from bar import Bar   File "q:\Programming\Python\loops\bar.py", line 1, in <module>     from foo import Foo   File "q:\Programming\Python\loops\foo.py", line 1, in <module>     from bar import Bar ImportError: cannot import name Bar

When this happens to you, the solution is usually to move the common objects from foo.py and bar.py to a different file (say common.py). However, sometime there's actually a real loop of dependencies. For example, a method in Bar needs to create a Foo instance and vice versa. When the dependency is in a limited scope, you should remember that you can use the import command wherever you want. Putting imports at the top of the file is the common convention, but sometimes you can solve import loops by importing in a smaller scope, like in a method definition.

Easter Eggs

What fun would an easter egg be if you didn't try it by yourself? Try these and have fun!

import antigravity import this from __future__ import braces import __hello__ from __future__ import barry_as_FLUFL

Related Python Posts

The Dictionary Playbook

hash, id and Dictionary Order

The frontend guys suggested this solution to our problem (excerpt from the original post):

The frontend guys would work on the VM we gave them. We’re still “in charge” of it, but we’re not allowed to modify any files. When we want to share versions of our code, we’ll use a third, public directory and copy our code manually to and from it. The merges will be done by hand from their side, and with Mercurial from our side.

This solution is bad. It's bad because it's a reinvention of the source control idea, only done manually so that the upshot of this would be that we will spend hours on end tinkering with diffs (removed files, especially, will be a nuisance) instead of actually developing. My team was pretty upset the days after this meeting. We were all frustrated with the new system we had to put up with, and we felt it was only because of internal politics and not actual technological reasons. We didn't want to work with the frontend guys anymore and we were unhappy. We wanted to escalate the issue to upper management so we don't have to work like this.

But our group leader (actually, his replacement) insisted that we give their way a chance. Not because their suggestion was good, but because it wasn't just bad, it was painstakingly bad. It was so bad that it could not possibly work out for anyone. And that's was he was counting on.

So we gave it a chance. The first thing we did was to show we were doing our part. We asked them to send us their version of the code and we merged it into our code base. It was annoying, complicated and it took a lot of time, but we did it without complaining (to them - we complained the hell out of it to our GL). Then, we sent them our code base, in it's entirety. While they are only responsible for a small directory with some HTML/CSS/JS files, which they could email us, our project is several hundred thousands line of code, which contains an entire Linux framework, with C, Cython, Python and a custom build system that also compiles the Linux kernel. They needed it all because the backend uses this framework and they couldn't run the server otherwise (as we explained to them in the original meeting). So, the zip was pretty big...

And now, we waited. They got the zip and used a diff tool to do the merge. After several hours, they started calling us for help. At day's end, they asked us, on a "one-time" basis, to use Mercurial to recreate their project for them. We refused. We told them it wasn't what we agreed to, and it's their way we're trying now. The next day, they still haven't gotten around to building the project as they still had trouble unzipping the directory. At one point they backed up their directory, wiped it clean and started over, and still they were unsuccessful. 

Another day went by, and we agreed to recreate their project. We sent out an email calling for another meeting to work out a new solution, but we got the following response:

There's no need to set up another meeting.

We didn't realize the size of the project we we're dealing with. We'll be happy if you teach us how to use Mercurial so we can work with that from now on.

Wasn't that a sight for sore eyes.

We felt victorious at last. Not only did we teach them Mercurial, they also started using it by connecting (via NX) to their dedicated Ubuntu VM, so in a way they're also using Linux now. And you know what? They're pretty happy with the new situation. They got up to speed really fast and started pushing changes to the code base.

The lesson to be learned here (other than the fact the source control is a necessity), is that sometimes the best way to make someone follow your path is to make him make his own mistakes and learn from them. I appreciate my GL very highly for keeping his cool and resolving this issue in such a peaceful and smart way.

QuerySets Are Awesome

A QuerySet, in essence, is a list of objects of a given model. I say 'list' and not 'group' or the more formal 'set' because it is ordered. In fact, you're probably already familiar with how to get QuerySets because that's what you get when you call various Book.objects.XXX() methods. For example, consider the following statement:

Book.objects.all()

What all() returns is a QuerySet of Book instances which happens to include all Book instances that exist. There are other calls which you probably already know:

# Return all books published since 1990 Book.objects.filter(year_published__gt=1990) # Return all books *not* written by Richard Dawkins Book.objects.exclude(author='Richard Dawkins') # Return all books, ordered by author name, then # chronologically, with the newer ones first. Book.objects.order_by('author', '-year_published')

The cool thing about QuerySets is that, since every one of these function both operates on and returns a QuerySet, you can chain them up:

# Return all book published after 1990, except for # ones written by Richard Dawkins. Order them by # author name, then chronologically, with the newer # ones first. Book.objects.filter(year_published__gt=1990) \             .exclude(author='Richard Dawkins') \             .order_by('author', '-year_published')

And that's not all! It's also fast:

Internally, a QuerySet can be constructed, filtered, sliced, and generally passed around without actually hitting the database. No database activity actually occurs until you do something to evaluate the queryset.

So we've established that QuerySets are cool. Now what?

Return QuerySets Wherever Possible

I've recently worked on a django app where I had a Model that represented a tree (the data structure, not the christmas decoration). It meant that every instance had a link to its parent in the tree. It looked something like this:

class Node(models.Model):     parent = models.ForeignKey(to='self', null=True, blank=True)     value = models.IntegerField()     def __unicode__(self):         return 'Node #{}'.format(self.id)     def get_ancestors(self):         if self.parent is None:             return []         return [self.parent] + self.parent.get_ancestors()

This worked pretty well. Trouble was, I had to add another method, get_larger_ancestors, which should return all the ancestors whose value was larger then the value of the current node. This is how I could have implemented this:

    def get_larger_ancestors(self):         ancestors = self.get_ancestors()         return [node for node in ancestors if node.value > self.value]

The problem with this is that I'm essentially going over the list twice - one time by django and another time by me. It got me thinking - what if get_ancestors returned a QuerySet instead of a list? I could have done this:

    def get_larger_ancestors(self):         return self.get_ancestors().filter(value__gt=self.value)

Pretty straight forward, The important thing here is that I'm not looping over the objects. I could perform however many filters I want on what get_larger_ancestors returned and feel safe that I'm not rerunning on a list of object of an unknown size. The key advantage here is that I keep using the same interface for querying. When the user gets a bunch of objects, we don't know how he'll want to slice and dice them. When we return QuerySet objects we guarantee that the user will know how to handle it.

But how do I implement get_ancestors to return a QuerySet? That's a little bit trickier. It's not possible to collect the data we want with a single query, nor is it possible with any pre-determined number of queries. The nature of what we're looking for is dynamic and the alternative implementation will look pretty similar to what it is now. Here's the alternative, better implementation:

class Node(models.Model):     parent = models.ForeignKey(to='self', null=True, blank=True)     value = models.IntegerField()     def __unicode__(self):         return 'Node #{}'.format(self.id)     def get_ancestors(self):         if self.parent is None:             return Node.objects.none()         return Node.objects.filter(pk=self.parent.pk) | self.parent.get_ancestors()     def get_larger_ancestors(self):         return self.get_ancestors().filter(value__gt=self.value)

Take a while, soak it in. I'll go over the specifics in just a minute.

The point I'm trying to make here is that whenever you return a bunch of objects - you should always try to return a QuerySet instead. Doing so will allow the user to freely filter, splice and order the result in a way that's easy, familiar and provides better performance.

(On a side note - I am hitting the database in get_ancestors, since I'm using self.parent recursively. There is an extra hit on the database here - once when executing the function and another in the future, when actually inspecting the results. We do get the performance upside when we perform further fliters on the results which would have meant more hits on the database or heavy in-memory operations. The example here is to show how to turn non-trivial operations into QuerySets).

Common QuerySet Manipulations

So, returning a QuerySet where we perform a simple query is easy. When we want to implement something with a little more zazz, we need to perform relational operations (and some helpers, too). Here's a handy cheat sheet (as an exercise, try to understand my implementation of get_larger_ancestors).

Union - The union operator for QuerySets is |, the pipe symbol. qs1 | qs2 returns a QuerySet with all the items from qs1 and all the items in qs2 while handling duplicates (items that are in both QuerySets will only appear once in the result).

Intersection - there is no special operator for intersection, because you already know how to do it! Chaining functions like filter and exclude are in fact performing an intersection between the original QuerySet and the new filter.

Difference - a difference (mathematically written as qs1 \ qs2) is all the items in qs1 that do not exist in qs2. Note that this operation is asymmetrical (as opposed to the previous operations). I'm afraid there is no built-in way to do this in python, but you can do this: qs1.exclude(pk__in=qs2)

Nothing - seems useless, but it actually isn't, as the above example shows. A lot of time, when you're dynamically building a QuerySet with unions, you need to start off with what would have been an empty list. This is how to get it: MyModel.objects.none().

  Related Posts

A Case for a OneToMany Relationship in Django

Python: hash, id and Dictionary Order

>>> bar = 42 ... def foo(): ... bar = 0 ... foo() ... print bar 42

We can see that foo ran fine and without exceptions, but if we print the value of bar we'll se that it's still 42! What happens here is that the line bar = 0, instead of changing bar, created a new, local variable also called bar and set its value to 0. This is a tough bug to find and it causes some grief to newbies (and veterans!) who aren't really sure of how Python's scoping works. To understand when and how Python decided to treat variables as global or local, let's look at a less common, but probably more baffling version of this mistake and add an assignment to bar after we print it:

bar = 42 def foo():     print bar     bar = 0

This shouldn't break our code, right? We added an assignment after the print, so there's no way it should affect it (Python is an interpreted language after all), right? Right??

>>> foo() Traceback (most recent call last):   File "<pyshell#4>", line 1, in <module>     foo()   File "<pyshell#3>", line 3, in foo     print bar UnboundLocalError: local variable 'bar' referenced before assignment

WRONG.

How is this possible? Well, there are two parts to this misunderstanding. The first misconception is that Python, being an interpreted language (which is awesome, I think we can all agree), is executed line-by-line. In truth, Python is being executed statement-by-statement. To get a feel of what I mean, go to your favorite shell (you aren't using the default one, I hope) and type the following:

def foo():

Press Enter. As you can see, the shell didn't offer any output and it's clearly waiting for you to continue with your function definition. It will continue to do so until you finish declaring you function. This is because a function declaration is a statement. Well, it's a compound statements, that includes within it many other statements, but a statement notwithstanding. The content of your function isn't being executed until you actually call it. What is being executed is that a function object is being created.

This leads us to the second point. Again, Python's dynamic and interpreted nature leads us to believe that when the line print bar is executed, Python will look for a variable bar first in the local scope and then in the global scope. What really happens here is that the local scope is in fact not completely dynamic. When the def statement is executed, Python statically gathers information regarding the local scope of the function. When it reaches the line bar = 0 (not when it executes it, but when it reads the function definition), it adds "bar" to the list of local variable for foo. When foo is executed and Python tries to execute the line print bar, it looks for the variable in the local scope and it finds it, since it was statically accessed, but it knows that it wasn't assigned yet - it has no value. So the exception is raised.

You could ask "why couldn't an exception be raised when we were declaring the function? Python could have known in advance that bar was referenced before assignment". The answer to that is that Python can't know whether the local bar was assigned to or not. Look at the following:

bar = 42 def foo(baz):     if baz > 0:         print bar     bar = 0

Python is playing a delicate game between static and dynamic. The only thing it knows for sure is that bar is assigned to, but it doesn't know it's referenced before assignment until it actually happens. Wait - in fact, it doesn't even know it was assigned to!

bar = 42 def foo():     print bar     if False:         bar = 0 >>> foo() Traceback (most recent call last):   File "<pyshell#17>", line 1, in <module>     foo()   File "<pyshell#16>", line 3, in foo     print bar UnboundLocalError: local variable 'bar' referenced before assignment

While we, intelligent beings that we are, can clearly see that the assignment to bar will never happen, Python ignores that fact and still declares bar as statically local.

I've been babbling about the problem long enough. We want solutions, baby! I'll give you two.

>>> bar = 42 ... def foo(): ... global bar ... print bar ... bar = 0 ... ... foo() 42 >>> bar 0

The first one is using the global keyword. It's pretty self-explanatory. It let's Python know that bar is a global variable and not local.

The second, more preferred solution, is - don't. In the sense of - don't use a global that isn't constant. In my day-to-day I work on a lot of Python code and there isn't one use of the global keyword. It's nice to know about it, but in the end it's avoidable. If you want to keep a value that is used throughout your code, define it as a class attribute for a new class. That way the global keyword is redundant since you need to qualify your variable access with its class name:

>>> class Baz(object): ... bar = 42 ... ... def foo(): ... print Baz.bar # global ... bar = 0 # local ... Baz.bar = 8 # global ... print bar ... ... foo() ... print Baz.bar 42 0 8

Read the rest of the series:

Part 1: Using a Mutable Value as a Default Value

Part 2: Scoping (YOU ARE HERE!)

Looking for more? Read some of my other Python posts:

The Dictionary Playbook

What else is there in Python?

Using a Mutable Value as a Default Value

This one definitely deserves its place at the top of the list. Not only is the reason for this "bug" subtle, it's also very hard to debug. Consider the following snippet*:

def foo(numbers=[]): numbers.append(9) print numbers

So we take a list (defaults to an empty list), add 9 to it and print it.

>>> foo() [9] >>> foo(numbers=[1,2]) [1, 2, 9] >>> foo(numbers=[1,2,3]) [1, 2, 3, 9]

Seems good, right? Except this is what happens when we call foo without numbers:

>>> foo() # first time, like before [9] >>> foo() # second time [9, 9] >>> foo() # third time... [9, 9, 9] >>> foo() # WHAT IS THIS BLACK MAGIC?! [9, 9, 9, 9]

So what's happening here? Our instincts tell us that whenever we call foo without numbers, then numbers will be assigned with an empty list. This is wrong. Default values for functions in Python are instantiated when the function is defined, not when it's called.

Still, you'd ask, why isn't the same pre-calculated value reassigned every time I call the function? Well, every time you specify a default value for a function, Python stores that value. If you call the function and override that default, the stored value is not used. When you don't override it (like in our example), Python makes the name you defined (numbers, in our case) reference the stored value. It does not copy the stored value to your variable. This may be a difficult concept for beginners, so imagine that instead of two distinct variables (one - the internal, initial default value and the other - the current, local variable), what we have in fact is two names that allow us to interact with the same value. So whenever numbers changes, it also changes Python's memory of what the initial value is.

The solution here is this**:

def foo(numbers=None):     if numbers is None:         numbers = []     numbers.append(9)     print numbers

More often than not, when people hear about this, they ask how come other default values do work as expected. Consider this:

def foo(count=0):     count += 1     print count

When we run it, it works percisely as expected:

>>> foo() 1 >>> foo() 1 >>> foo(2) 3 >>> foo(3) 4 >>> foo() 1

Why is that? The "secret" here is not in the default value assignment, but in the value itself. An integer is an immutable type. While, like the empty list, it is executed in the definition of the function, it cannot be changed. When we do count += 1 we do not change the original value of count. We simply make the name count point to a different value. However, when we do numbers.append(9) we do change the original list. Hence, the confusion.

There is another variety of this same problem when you try to call a function as the default value:

def print_now(now=time.time()):     print now

As before, while the value of time.time() is immutable, it is calculated only when the function is defined, so it'll always return the same time - the time when the function code was parsed by Python:

>>> print_now() 1373121487.91 >>> print_now() 1373121487.91 >>> print_now() 1373121487.91

* This problem and its solution are relevant in both Python 2.x and 3.x, with the sole difference that with Python 3.x, the print statements should be function calls (e.g., print(numbers)).

** You'll notice that I used if numbers is None in the solution and not if not numbers. This is another common mistake which I already dedicated a post to, and you can find it here.

Read the rest of the series:

Part 1: Using a Mutable Value as a Default Value (YOU ARE HERE!)

Part 2: Scoping

Looking for more? Read some of my other Python posts:

The Dictionary Playbook

What else is there in Python?

Here's a watered-down version of the code we were debugging:

class TableA(object): pass class TableB(object): pass class TableC(object): pass class Poller(object):     TABLES = {TableA: '1',               TableB: '2',               TableC: '3'}     def poll(self):         for table, value in self.TABLES.iteritems():             # look for an entry             print table             return p = Poller() p.poll()

The real bug was the return statement - we did it regardless of whether we found the entries or not, while we should have only returned if we found them (if not, we should continue the loop to the other entries), but that's a side issue for now. The result of this bug was that only one table was checked when we called poll. Specifically, the entry we were looking for was in TableC, but the code only polled TableA. When we added the pdb statement, however, it only polled TableC (which seemed to solve the bug). So the order in which the dictionary returned the items was consistent as long as no code changes were introduced. Yep, we also tried to add other function calls like sleep(1) with the same result. 

So let's do some testing. I took the following piece of code (very similar to the code above) and run it several thousand times:

class A(object): pass class B(object): pass class C(object): pass class D(object): pass class E(object): pass class F(object): pass class G(object): pass class H(object): pass class Foo(object):     d = {A: 1, B: 2, C: 3, D: 4,          E: 5, F: 6, G: 7, H: 8}     def bar(self):         for key, value in self.d.iteritems():             print key.__name__, f = Foo() f.bar()

The result is that in every run the order is static and happens to be:

H A F E D B C G

That kind of surprises me, so let's continue with the testing and add some redundant code to the end of our script:

import time time.sleep(0)

Now see what happens - again, the order is static but it changes from the first version of our code. Now it looks like this:

F A E D G B H C

So let's figure out what was happening here.

To understand what determines the order of the items in iteritems() we need to first understand a bit about the internals of CPython's dict implementation [attribution]:

Python dictionaries are implemented as hash tables.

When a new dictionary is initialized it starts with 8 slots.

When adding entries to the table, CPython uses a mask to take the x most lower bits of the entry's hash and uses these bits to determine the entry's initial location. When the dictionary has 8 slots, x is 3.

When the initial slot for an entry is taken, CPython uses (psuedo) random probing to select a new location, that uses the other bits of the entry's hash.

The default CPython implementation of the __hash__ method is id(entry)/16.

In turn, the default id implementation is simply the object's memory address.

The order of the items that iteritems returns is the same as their order in the slots - slot 0 first, then slot 1, etc.

I found that in every run, every class' hash was different. It makes sense, because the memory addresses change by what is available to the Python process. However, I also found that in every single run - the lower 3 bits of every class' hash remained equal. These are the values for classes A..H respectively with the first version of the code:

0 2 3 5 0 4 6 5

That's the reason their order remained the same. Can you guess what happens with the second version? The lower three bits have different values than the first version! And this is consistent across multiple runs. And remember, not only did we only add redundant lines of code - it was also after the classes were instantiated, so naively we wouldn't expect it to have any effect! Here are the values - again, for classes A..H respectively:

0 2 5 0 2 4 5 6

Semantics

The many-to-one relationship that Django provides is ForeignKey. A foreign key is always declared on the "one" side of the relationship, e.g., if you have a Band model and each Band has several Musician models related to it, then you would put a ForeignKey in the Musician model like so:

class Band(models.Model):     # ... class Musician(models.Model):     # ..     band = ForeignKey(to=Band, related_name="members", null=True, blank=True)

This way, every musician has a band related to it, and bands may have musicians related to them, but this is the wrong way around! Musicians exist without bands. Some are in bands, some aren't. Even those who are in a band aren't defined by it. However, a band is determined by its members. A band without members cannot exist. So, there's a semantic issue here. Therefore, I suggest the following syntax:

class Band(models.Model):     # ...     members = OneToMany(to=Musician) class Musician(models.Model):     # ..

This way - every band has musicians. Musicians may be in bands, but not necessarily. And, and this is the difference between the proposed OneToMany and the already-existing ManyToMany, each musician is in only one band.

Readability

Let's toss some more models into the mix. Suppose we have music agents and each one of them has musicians as clients. Perhaps we also have different musician unions. Using ForeignKey again, it'll look like this:

class Band(models.Model):     # ... class Agent(models.Model):     # ... class Union(models.Model):     # ... class Musician(models.Model):     # ..     band = ForeignKey(to=Band, related_name="members", null=True, blank=True)     agent = ForeignKey(to=Agent, related_name="clients", null=True, blank=True)     union = ForeignKey(to=Union, related_name="members", null=True, blank=True)

Again, for Agent and Union (like Band before), it's confusing that a required piece of information about them is defined elsewhere, while in Musician there are so many optional members that clutter up what's important about the musician. Here's how it'll look like with OneToMany relationships:

class Band(models.Model):     # ...     members = OneToMany(to=Musician) class Agent(models.Model):     # ...     clients = OneToMany(to=Musician) class Union(models.Model):     # ...     members = OneToMany(to=Musician) class Musician(models.Model):     # ..

Every model contains all of its required information and at the same time they are not cluttered with a bunch of optional members. With ForeignKey, the more "musician groups" we have, the more clutter is gathered in the Musician model. So OneToMany helps keep the information where it has the most meaning to you, the programmer.

Extensibility

The previous example also suggests another advantage of the relationship. When working with an already-existing model, both OneToOne and ManyToMany relationships allow us to add information to that model without altering its source code. However, when adding a many-to-one relationship, you must always place the ForeignKey in the "one" side, which may be a model which you can't change, for any number of reasons (e.g., working with a library, or working with code that is common to several applications). The OneToMany relationship allows us to break that barrier.

  More Python-related Posts

The Dictionary Playbook

What else is there in Python?

Related Articles:

So what is this about? If you take a look at screen's man pages you'll read that:

Screen is a full-screen window manager that multiplexes a physical terminal between several processes (typically interactive shells).