[Web-SIG] WSGI deployment part 2: factory API

Ian Bicking ianb at colorstudy.com
Mon Jul 25 05:26:29 CEST 2005


Phillip J. Eby wrote:
>> Another option is we pass in a single dictionary that represents the
>> entire configuration.  This leaves room to add more arguments later,
>> where if we use keyword arguments for configuration then there's really
>> no room at all (the entire signature of the factory is taken up by
>> application-specific configuration).
> 
> 
> YAGNI; We don't have any place for this theoretical extra configuration 
> to come from, and no use cases that can't be met by just adding it to 
> the configuration.  Early error trapping is important, so I think it's 
> better to let factories use normal Python argument validation to have 
> required arguments, optional values, and to reject unrecognized arguments.

I think in practice I'll always take **kw, because I otherwise I'd have 
to enumerate all the configuration all the middleware takes, and that's 
impractical.  I suppose I could later assemble the middleware, determine 
what configuration the actual set of middleware+application takes, then 
check for extras.  But I doubt I will.  And even if I do, it's 
incidental -- I'm quite sure I won't use using the function signature 
for parameter checking.

>> Another part of the API that I can see as useful is passing in the
>> distribution object itself.
> 
> 
> Which distribution?  The one the entry point came from?  It already 
> knows (or can find out) what distribution it's in.

I mean like:

   [wsgi.app_factory]
   filebrowser = paste.wareweb:make_app

Where paste.wareweb.make_app knows how to build an application from 
filename conventions in the package itself, even though the 
paste.wareweb module isn't in the project itself.

-- 
Ian Bicking  /  ianb at colorstudy.com  / http://blog.ianbicking.org


More information about the Web-SIG mailing list