[mod_python] object type. why it not works?

On 24/06/07, Jeff Hinrichs - DM&T <jeffh at dundeemt.com> wrote:
> On 6/23/07, ziapannocchia at gmail.com <ziapannocchia at gmail.com> wrote:
> > I have a selfmade apache server, and I'm writing  a little web
> > application with mod python.
> >
> > Using this def:
> >
> > def testPython(contenuto):
> >   test="test"
> >   return type(test)
> >
> > I obtain this error:
> >
> > Mod_python error: "PythonHandler mod_python.publisher"
> >
> > Traceback (most recent call last):
> >
> >   File "/usr/lib64/python2.4/site-packages/mod_python/apache.py", line
> > 299, in HandlerDispatch
> >     result = object(req)
> >
> >   File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
> > line 213, in handler
> >     published = publish_object(req, object)
> >
> >   File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
> > line 412, in publish_object
> >     return publish_object(req,util.apply_fs_data(object, req.form, req=req))
> >
> >   File "/usr/lib64/python2.4/site-packages/mod_python/publisher.py",
> > line 412, in publish_object
> >     return publish_object(req,util.apply_fs_data(object, req.form, req=req))
> >
> >   File "/usr/lib64/python2.4/site-packages/mod_python/util.py", line
> > 401, in apply_fs_data
> >     fc = object.__init__.im_func.func_code
> >
> > AttributeError: 'wrapper_descriptor' object has no attribute 'im_func'
> >
> > Instead, on command line, the same istruction works well:
> >
> > cloc3 at s939 /home/cloc3 $ python
> > Python 2.4.4 (#1, May 18 2007, 08:25:49)
> > [GCC 4.1.2 (Gentoo 4.1.2)] on linux2
> > Type "help", "copyright", "credits" or "license" for more information.
> > >>> test="test"
> > >>> type(test)
> > <type 'str'>
> >
> >
> > What may be wrong?
>
> Publisher wants to return a string -- and you are attempting to return
> an object, http://docs.python.org/lib/bltin-type-objects.html
>
> try, return test  --or-- return str(type(test))

Actually, you are supposed to be able  to return anything from a
published function which can be converted to a string. Thus one can
return integers, dictionaries, lists, or custom data types provided
they defined a __str__() method.

Now, there is actually a problem here and it derives from fact that
publisher does something that I didn't even realise. Question is
whether it is an inadvertent feature added by accident or whether it
was intentional.

The problem is with the function:

def publish_object(req, object):
    if callable(object):

        # To publish callables, we call them an recursively publish the result
        # of the call (as done by util.apply_fs_data)

        req.form = util.FieldStorage(req, keep_blank_values=1)
        return publish_object(req,util.apply_fs_data(object, req.form, req=req))

    else:
       ...

The intent of this function is that it is called with the object which
the URL got matched to. If the target wasn't callable then resulted
would be that it gets converted to a string and written back as
response.

If the target was callable, then util.apply_fs_data() is called to
actually make the call against the target object. The result of this
is then passed back into publish_object() in a second call to have the
resulted converted to a string and written back as response.

Problem is that in calling publish_object() a second time, if the
result of calling util.apply_fs_data() was itself a callable, then a
subsequent attempt will be made to call that.

At this point I am going to assume that this wasn't intentional, and
if it was then it has a bug for other reasons besides what is being
seen. Namely, it creates an instance of util.FieldStorage on every
call and assigns it to req.form. This means that form data would get
wiped on a recursive call to a second callable object. If the feature
was intentional, then it should check to see if req.form exists and
use it rather than creating util.FieldStorage.

So, there are a few issues here that need to be sorted out.

1. Should publisher invoke a callable object returned by a function.

2. If answer to 1 is yes, then how form data is managed needs to be fixed.

3. If answer to 1 is yes, then before recursively calling a callable
then publisher should apply its rule set to ensure it isn't calling an
object type it isn't supposed to.

In respect of 3, if one has:

  index = type("test")

then accessing index will result in Forbidden response as rule set
denies access, not so with the recursive call though.

Anyone got any opinions on whether publisher should do 1?

Graham