Issue #883 resolved

getting errors in dispatcher after updating to python 2.5 from 2.4

Anonymous created an issue

Hi, we spoke in #cherrpy briefly. Fumanchu told me to make this ticket.

I'm getting this error when requests to my objects are made.

{{{ [15/Dec/2008:14:56:07] HTTP Traceback (most recent call last): File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/CherryPy-3.1.1-py2.5.egg/cherrypy/_cprequest.py", line 606, in respond cherrypy.response.body = self.handler() File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/CherryPy-3.1.1-py2.5.egg/cherrypy/_cpdispatch.py", line 27, in call test_callable_spec(self.callable, self.args, self.kwargs) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/site-packages/CherryPy-3.1.1-py2.5.egg/cherrypy/_cpdispatch.py", line 49, in test_callable_spec (args, varargs, varkw, defaults) = inspect.getargspec(callable) File "/Library/Frameworks/Python.framework/Versions/2.5/lib/python2.5/inspect.py", line 742, in getargspec raise TypeError('arg is not a Python function') TypeError: arg is not a Python function }}}

I'm mounting my object directly with cherrypy.tree.mount(mySearchHandler,'/keyword',keyword_conf)

Check this out: http://kbyanc.blogspot.com/2007/07/python-more-generic-getargspec.html

It says getargspec() is only supposed to work for functions and methods, not other python callable objects. Somehow (magic?) it works for me most of the time, but certain (buggy) code seems to cause my call method to not be callable. The tricky thing is that I don't get any relevant info in the stack trace, only the stack trace above.

Reported by ryan@finetune.com

Comments (8)

  1. Anonymous

    Fixed (mostly) in [2084] It turns out that once I fixed the callable object problem the underlying exception was propagated properly.

    there is still the possibility that test_callable_spec will fail by raising an exception. For instance a TypeError if the handler is a builtin or something. In that case we may end up hiding the users exception as well.

    I guess we might be able to fix that by doing something to the effect of:

    try:
        return self.callable(*self.args, **self.kwargs)
    except TypeError, x:
        try:
            test_callable_spec(...)
        except cherrypy.HTTPError:
            raise
        except:
           raise x
    

    fumanchu - what do you think?

  2. Anonymous

    [2085] helped me when looking at the test cases in #869 so I'm committing it cause it's better than not having it.

  3. Christian Wyglendowski

    Just chiming in here ...

    I don't think that a 404 with a "Missing Parameters: %s" message is appropriate for a handler and request like the following:

    ...
        @cherrypy.expose
        def entry(self, id, format):
            return "Here is entry %s in %s format." % (id, format)
    
    GET /entry/12 HTTP/1.1
    

    They aren't really parameters in that case. I also think that leaks too much information out of the app to whomever made the request. IMO a standard "Not Found" message is better. What do you guys think?

  4. Anonymous

    Hrmm. I see your point about leaking information.

    I originally put them in to aid developers who were unexpectantly getting a 404 because they were missing URI parameters. Think of the poor PHP developers.

    I wonder if there is a way to change it based on whether its in production or not. Like does the stacktrace still appear when people set the environment to production? If not, then maybe hiding it whenever the stack trace is hidden is best.

  5. Anonymous

    Ability to turn off the messages about mismatched parameters added in[2093]. Defaults to True but is turned off in production/staging.

  6. Log in to comment