[mod_python] Setting PythonOption to an empty string.

On Oct 05 06:28, Rich McDonough <rich.mcdonough at rawkin.net> wrote:
>
> Subject: Re: [mod_python] Setting PythonOption to an empty string.
>
> For the sub-directory you will need a directive that states:
> 
> SetHandler None
> 
> Graham Dumpleton wrote:
> > I might be missing something, but I want to be able to set a 
> > PythonOption variable
> > to be an empty string. Alternatively, is there a way in the .htaccess 
> > file to unset
> > a PythonOption variable which has been inherited from a parent directory?
> > 
> > When I try and set the variable to an empty string. Ie.,
> > 
> >   PythonOption Name ""

In my haste last night, I managed to reply only to the responder and not the
whole list, so here we go again, but with more detail this time. In short,
the above response isn't what I am asking about. I am not wanting to disable
mod_python in the subdirectory, only wipe out the value of the PythonOption
option setting. Hmmm, now I see why it didn't go to the list, the sender
didn't send it there, but only to me. Anyway, hope this email explains it
better.

Consider the following .htaccess file and content handler.

# .htaccess

  AddHandler python-program .py
  PythonHandler vartest
  PythonDebug On
  PythonOption NAME VALUE1

# vartest.py

  from mod_python import apache

  def handler(req):
    req.content_type = "text/plain"
    req.send_http_header()
    req.write("FILENAME = "+req.filename+"\n")
    req.write("PATH_INFO = "+req.path_info+"\n")
    req.write("NAME = "+req.get_options().get("NAME","UNDEFINED")+"\n")
    return apache.OK

When I request a .py file in that specific directory, I get:

  FILENAME = /Users/grahamd/Sites/modpython/dummy.py
  PATH_INFO = 
  NAME = VALUE1

Now create a subdirectory with another .htaccess file.

# subdir/.htaccess

  PythonOption NAME VALUE2

When I request a .py file out of the subdirectory, I get:

  FILENAME = /Users/grahamd/Sites/modpython/subdir/dummy.py
  PATH_INFO = 
  NAME = VALUE2

In other words, the AddHandler/PythonHandler from the parent directory
still dictate that mod_python be used, but the PythonOption setting from
the subdirectory overrides that from the parent when the path being accessed
falls within the subdirectory.

Now, if the setting of NAME in the subdirectory .htaccess is commented out
and the subdirectory request done again, I get:

  FILENAME = /Users/grahamd/Sites/modpython/subdir/dummy.py
  PATH_INFO = 
  NAME = VALUE1

Thus you can see that the setting of NAME in the parent directory is inherited
by a subdirectory if it isn't overridden.

The problem now is that once a parent sets a value using PythonOption, the
only thing one can do in a subdirectory is to override it with some other non
empty value. This is because the following results in a internal server error.

  PythonOption NAME ""

I have tried other variations on this, but can't find any that allow me to set the
value to an empty string. I can't see any evidence that one can totally unset a
value either. If there is no valid non empty value that you can use for a value
to effectively say its value should be ignored, you are stuffed. Luckily in my
case it was reasonable to say that if the value was set to "." that the code relying
on it default back to standard behaviour.

Note that even if "vartest.py" was outside of the document tree and the subdir
used AddHandler/PythonHandler again, it doesn't start a new context for options
and NAME is still inherited from the parent.

Even if this did work, it isn't want I wanted as it has other implications such as
the path of both the parent and subdirectory being put in "sys.path". In some
cases it is problematic enough that the document directory is put in "sys.path" at
all, but you can't get around this though when the content handler is in the actual
document tree. Luckily, if the module is somewhere else outside the document
tree and on your normal Python path, you can at least say:

  PythonPath 'sys.path'

This has the affect of leaving sys.path how it was before that directory was
encountered, which is much safer to my mind, but then you need a module loader
where you can say exactly which directory you want a module pulled from as
"import" ain't going to and possibly not "import_module()" either.

Enough rambling.

--
Graham Dumpleton (grahamd at dscpl.com.au)