[mod_python] Subclassing Session

Jim Gallacher jpg at jgassociates.ca
Tue Jul 18 14:08:50 EDT 2006

Thomas J. Schirripa wrote:
> Thanks for the help Jim. I just wanted to add that I am not really sure about the implementation of those 4 methods you suggested because they aren't in the docs, but I am going to take a look at the source code and figure out what they're doing.
> Thanks again,
> Tom

They are just hooks that do the actual work for load(), save(), delete()
and cleanup(), all of which are documented. These documented methods do
some generic processing, and then call the respective do_* methods to
handle the lower level work specific to a particular session data store.

MemorySession is the simplest BaseSession subclass, so you might find it
helpful to examine its code first and use that as your template.


> -----Original Message-----
>> Date: Tue Jul 18 13:12:58 EDT 2006
>> From: "Jim Gallacher" <jpg at jgassociates.ca>
>> Subject: Re: [mod_python] Subclassing Session
>> To: "Thomas J. Schirripa" <tommys at eden.rutgers.edu>
>> Thomas J. Schirripa wrote:
>>> Before stating my problem, let me say that I am running apache version 2.0.52, mod_python 3.2.8, python 2.3, all on Redhat Enterprise Linux WS release 4.
>>> I am making some basic web utilities that require that I create sessions. Essentially, I want to use session ids created by mod_python to create a session folder where I can temporarily dump files  and manipulate stuff so I can generate some output for the client. Since I would be using this feature a lot, I thought it would be a good idea to make a subclass of BaseSession that added this functionality of making a folder with the session name. I made a file located somewhere else on my machine called SessDirectory.py, and it defines the class SessionDirectory. The file looks like this:
>>> from Session import BaseSession
>>> import os
>>> class SessionDirectory(BaseSession):
>>> 	def __init__(self, req, path=None, sid=None, secret=None, lock=1, timeout=0):
>>> 		BaseSession.__init__(self, req, sid, secret, lock, timeout)
>>> 		if path == None:
>>> 			self.absPath = os.path.join(os.getcwd(), sid)
>>> 		else:
>>> 			self.absPath = os.path.join(path, sid)
>>> 		os.mkdir(self.absPath, mode=0755)
>>> It can take an absolute path to create the session directory, or it can take no path, in which case it creates the session directory in the current directory. When I try to instantiate the SessionDirectory object, the following exception is raised:
>>> AttributeError: 'SessionDirectory' object has no attribute 'do_load'
>>> I did some fishing around and looked at the source code of the session module. Apparently, BaseSession has a method called "load()" that makes a call to "do_load()". BaseSession does not define "do_load()", HOWEVER, it seems that the built in sublcasses of BaseSession (ie- FileSession, DbmSession, etc) all define a "do_load()" method.
>>> My background is really in Java, and to me, it seems like BaseSession is an abstract class, but it has no signature for "do_load()" and I believe the exception would have been NotImplemented or something like that if there was a required implementation missing. 
>> This is a good suggestion, and it would make it easier to subclass
>> BaseSession if the following methods existed and raised NotImplemented.
>>  I suppose this info should be included in the docs as well and since I
>> have the magic powers required I shall make it so. :)
>> Offhand I'd say the 4 methods you'll need to implement are:
>> do_load()
>> do_save()
>> do_delete()
>> do_cleanup()
>> For your application do_delete and do_cleanup may be noop, as I'm sure
>> you'll want to preserve your data.
>>> Also, why does BaseSession inherit from "dict" and not "UserDict". I wanted to see if "dict" had a "do_load()" method, but if it did, then the instantiation of SessionDirectory should have called the "do_load()" from dict. 
>> I'm not sure I get your point about the superiority of UserDict.
>> According to the python docs, inheriting from dict is preferred:
>> """
>> UserDict -- Class wrapper for dictionary objects
>> Note: This module is available for backward compatibility only. If you
>> are writing code that does not need to work with versions of Python
>> earlier than Python 2.2, please consider subclassing directly from the
>> built-in dict type.
>> """
>> Jim
> _______________________________________________
> Mod_python mailing list
> Mod_python at modpython.org
> http://mailman.modpython.org/mailman/listinfo/mod_python

More information about the Mod_python mailing list