To __slots__ or not to __slots__?

Posted by tkouts on 18 February 2009 | 0 Comments

Tags: __slots__, agile, schema

In one of the previous Porcupine releases I decided to add the Python's __slots__ class attribute to every class which is schema related. This was done in favor of smaller memory consumption since these classes don't have a dictionary (the __dict__ attribute) for keeping instance variables.

But practice has shown that this addition was a move against flexibility. Whenever a schema update is required, this also requires database updates in order to add new or remove old attributes. Apart from this, the __slots__ attribute is known for breaking multiple inheritance.

Therefore, I'm thinking of removing the __slots__ attribute from all schema related classes in the upcoming version. Whenever a schema update is required, this will only be done at the Python class level, without requiring database updates. But then, in case of an attribute removal the persisted objects will continue to have the specific attribute. So when will this attribute be actually removed? The answer is the next time the object is updated.

I'm much more in favor of a flexible database that is self adjusting to schema updates than having a rigid schema that requires database updates every time it is changed (see relational databases). The natural fit for dynamic language is a dynamic self adjusting storage.

Post your comment


No one has commented on this page yet.

RSS feed for comments on this page | RSS feed for all comments

Clicky Web Analytics