Question

Suppose we have the following code:

class A:
    var = 0
a = A()

I do understand that a.var and A.var are different variables, and I think I understand why this thing happens. I thought it was just a side effect of python’s data model, since why would someone want to modify a class variable in an instance?

However, today I came across a strange example of such a usage: it is in google app engine db.Model reference. Google app engine datastore assumes we inherit db.Model class and introduce keys as class variables:

class Story(db.Model):
    title = db.StringProperty()
    body = db.TextProperty()
    created = db.DateTimeProperty(auto_now_add=True)
s = Story(title="The Three Little Pigs")

I don’t understand why do they expect me to do like that? Why not introduce a constructor and use only instance variables?

Answer 1

The db.Model class is a ‘Model’ style class in classic Model View Controller design pattern.
Each of the assignments in there are actually setting up columns in the database, while also giving an easy to use interface for you to program with. This is why

title="The Three Little Pigs"

will update the object as well as the column in the database.

There is a constructor (no doubt in db.Model) that handles this pass-off logic, and it will take a keyword args list and digest it to create this relational model.

This is why the variables are setup the way they are, so that relation is maintained.

Edit: Let me describe that better. A normal class just sets up the blue print for an object. It has instance variables and class variables. Because of the inheritence to db.Model, this is actually doing a third thing: Setting up column definitions in a database. In order to do this third task it is making EXTENSIVE behinds the scenes changes to things like attribute setting and getting. Pretty much once you inherit from db.Model you aren’t really a class anymore, but a DB template. Long story short, this is a VERY specific edge case of the use of a class