92e42ca3aa
Closing the underlying sqlite3 db on object destruction (__del__()) causes funny race conditions when concurrently accessing the object itself. When the Garbage Collector tries to free memory, which can happen when no more references pointing to self are used, by calling __del__() (which called close()) it is possible to run into troubles if another thread is inside a method of the same object holding a valid sqlite cursor. Moreover, no external arbitration is possible if the garbage collection gets in the middle and calls close() through the destructor on behalf of a poor random innocent thread. Solution is simple, destructor is evil and resource leaks have to be handled where they actually are. Bye bye __del__().