Jim Gallacher commented on MODPYTHON-127:

I've scanned the source and I think you have caught all the instances that need 

Are we sure we want to use CamelCase in the option names? I think this may be 
confusing if there is not a 1:1 correspondence between the PythonOption key and 
actual module namespace. So should it be


I'd rather not use CamelCase if we don't have a 1:1 mapping between the 
PythonOption key and the fully qualified class name. So either use

I'd avoid using mod_python.BaseSession, and just use mod_python.session for 
global session options. Using BaseSession just exposes an implementation detail 
and does not make the intent any clearer. Plus 

Again, notice the potential confusion with the camel case. session.Session is a 
factory function, so should mod_python.Session.some_option only control the 
behaviour of that function, or is it intended as global option for all session 
classes? What if a user creates a session instance directly, bypassing 
session.Session() - should mod_python.Session.some_option still be used?

I think for your proposed changes for the FileSession options are logical and 
should be adopted. I wonder though if we should refactor the constructor to use 
the new names as well? It would certainly be easier to do this now as 
FileSession may not be widely adopted yet. Consistency is a good thing after 

There is no conflict using session_directory for both DbmSession and 
FileSession. DbmSession creates a dbm file (/session/directory/mp_sess.dbm) in 
the directory, while FileSession creates its file hiearchy its own subdirectory 
(/session/directory/mp_sess/). Of course people are free to use 
mod_python.DbmSession.database_filename /session/directory/mp_sess to mess 
things up, but there is not much we can do about that.

My original thinking was that the session directory would be global to any 
session class that needs it. Should that directory flip back to the default 
(/tmp) just because I decide to use a different session class? Of course we 
could have it both ways: 

if 'mod_python.session.FileSession.database_directory' in options
   use it
  use mod_python.session.database_directory

> Use namespace for mod_python PythonOption settings.
> ---------------------------------------------------
>          Key: MODPYTHON-127
>          URL: http://issues.apache.org/jira/browse/MODPYTHON-127
>      Project: mod_python
>         Type: Improvement
>   Components: core
>     Versions: 3.3
>     Reporter: Graham Dumpleton

> In the interests of avoiding name clashes, I want to push that where 
> mod_python uses its own PythonOption settings, that they use a namespace. For 
> example:
>     PythonOption mod_python.session_cookie_name ...
>     PythonOption mod_python.ApplicationPath ...
>     PythonOption mod_python.session_dbm ...
>     PythonOption mod_python.session_fast_cleanup ...
>     etc ....
> If appropriate for mod_python, multiple levels of naming should be used. For 
> example, "session_fast_cleanup" is actually related to FileSession, so 
> perhaps it should be:
>   PythonOption mod_python.Session.cookie_name ...
>   PythonOption mod_python.Session.application_path ...
>   PythonOption mod_python.DbmSession.database ...
>   PythonOption mod_python.FileSession.fast_cleanup ...
> Thus, class name is interjected as second level in name. Also would like to 
> see final attribute name settle on lower case with underscore between 
> distinct words.
> We can support old names in mod_python for the time being but should 
> deprecate them.
> Any third party package developers should be strongly encouraged to also put 
> any of their own PythonOption settings names in their own unique namespace.
> Mailing list thread where this was first proposed, and in case there were 
> followups of interest, was:
>   http://www.modpython.org/pipermail/mod_python/2006-February/020213.html

This message is automatically generated by JIRA.
If you think it was sent incorrectly contact one of the administrators:
For more information on JIRA, see:

Reply via email to