[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