Ian Bicking: a blog

11 Comments

• Sergey Schetinin says:

  May 22, 2009 at 9:32 pm

  Having a third method is not a problem, I think. I suppose wsgify code would look like this:

  @wsgify
  def form(self, req, errors=None):
     ....
  
  @wsgify
  def form_post(self, req):
      if req not valid:
          return self.form(req, errors)
      ...
  

  With third method it’s almost the same:

  def gen_form(self, req, errors=None):
     ....
  
  form = webob_wrap(gen_form) # change 1
  
  @webob_wrap
  def form_post(self, req):
      if req not valid:
          return self.gen_form(req, errors) # change 2
      ...
  

  Overriding gen_form wouldn’t automatically override .form though.

  Are there more cases to justify extra parameter passing to wrapped methods? For this one having a separate method looks like the correct solution.

  (BTW, “Markdown formatting” link is broken)
• Armin Ronacher says:

  May 26, 2009 at 12:08 am

  Hi Ian.

  Just quickly had a look at the implementation and it seems overly complex to me. I’ve had exception handling in an early version of the “Request.application” decorator in Werkzeug as well and it turned out to be a mistake. It’s easier to write a simple try/except than configuring a decorator to handle some exceptions (like 404 not found).

  Right now the full implementation is a two liner and works: [Request.application](http://dev.pocoo.org/projects/werkzeug/browser/werkzeug/wrappers.py?rev=788%3A901b6c157194#L162)

  I think you’re slightly over-engineering your decorator here.
  • Ian Bicking says:

    May 26, 2009 at 11:36 am

    Why was exception handling a mistake? I’ve never found the HTTP* exceptions to be particularly problematic (at least on this scale — raising them across WSGI boundaries is bad).
• Ian Bicking says:

  May 28, 2009 at 11:16 am

  I’ve added another feature, wsgify.instantiate which can be used to create controller-like classes, something like:

  class MyClass(object):
      def __init__(self, req):
          self.req = req
      def __call__(self):
          return Response('whatever')
      wsgi_app = wsgify.instantiator()
  

  Then MyClass.wsgi_app is a WSGI application that will instantiate the class for every call. You could then create a web.py-style class like this:

  class ByMethod(object):
      def __init__(self, req):
          self.req = req
      def __call__(self):
          method = getattr(self, self.req.method, None)
          if method is None:
              raise exc.HTTPMethodNotAllowed()
          return method()
      wsgi_app = wsgify.instantiator()
  
  class Whatever(ByMethod):
      def GET(self): ...
      def POST(self): ...
  
  • Sergey Schetinin says:

    May 28, 2009 at 1:44 pm

    Or, one could make the class object itself a WSGI app via baseclass:

    from pasteob import *
    
    class PerRequest(object):
        class __metaclass__(type):
            @webob_wrap
            def __call__(cls, req):
                return type.__call__(cls, req)()
    
        def __init__(self, req):
            self.req = req
    
    ####
    
    class MyClass(PerRequest):
        def __call__(self):
            return Response('whatever')
    
    print Request.blank('/').get_response(MyClass)
    

    This can’t get any more concise and this wasn’t even a design consideration for webob_wrap.

    [Sorry for stalking your webob.dec effort, I hope this feedback is not entirely unwanted.]
    • Ian Bicking says:

      May 28, 2009 at 2:33 pm

      Metaclasses just scare the heck out of me for something like this.

      Another detail that has made some things harder is that I like custom Request/Response subclasses, and I want the decorator to be at least somewhat orthogonal to those classes, so you have to have some way to add parameters to these things.

      One thing that I may have over-thought is whether something like .wsgi_app should just be a very straight class method for this case.
      • Sergey Schetinin says:

        May 28, 2009 at 2:55 pm

        I wonder how do you customize the Request subclasses? I mean what do you put there that wouldn’t fit in webob itself — I can’t remember if I ever needed something like that.
        • Ian Bicking says:

          May 28, 2009 at 3:00 pm

          Well, here’s an example of a few minor things: http://bitbucket.org/ianb/pickywiki/src/tip/pickywiki/reqobj.py

          There’s several class variables on Request and Response that are intended for customization, and any WSGI extension could potentially be represented with a method on the request.
        • Ian Bicking says:

          May 28, 2009 at 4:07 pm

          Also you could [pretend you are Django](http://svn.pythonpaste.org/Paste/WebOb/branches/ianb-decorator-experiment/webob/django.py)
• Ian Bicking says:

  June 1, 2009 at 11:45 am

  It occurs to me with WSGI 2 that it will be relatively easy to stuff both WSGI and the request/response calling convention into __call__. And maybe it’s worth doing that even for WSGI 1… it’s just a simple type check, really, and an optional start_response argument in WSGI 1 (gone from WSGI 2)
• louis vuitton says:

  June 16, 2009 at 2:02 am

  i think is right,instead it adds an attribute .wsgi_app which is WSGI application associated with the function,Are there more cases to justify extra parameter passing to wrapped methods? For this one having a separate method looks like the correct solution.