At 10:26 PM 7/24/2005 -0500, Ian Bicking wrote:
>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.
Well, I'm sure I will for simple things. For more complex things, I'll use
the pattern of checking **kw against class attributes to make sure they
exist. PEAK, for example, already has this ability built-in, so it's
definitely the path of least resistance for implementing a middleware
component in PEAK; just subclass binding.Component and add attribute
bindings for everything needed. I'd hate to give that up for a theoretical
argument that someday we might need some kind of arguments that aren't
arguments. It's not as if we couldn't define a new protocol, and a
different modifier in the deployment descriptor, if that day ever actually
arrived.
>>>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.
Oh. I think I get you now; you want to be able to define an entry point
that wraps itself in something else. I don't see though why I can't just
put the wrapper code in myself, like this:
def my_app(*args, **kw):
return paste.wareweb.make_app(
pkg_resources.get_provider(__name__), *args, **kw
)
And then just make the entry point refer to this. Or, if you want to be fancy:
my_app = paste.wareweb.app_maker(__name__)
This seems more than sufficient for the use case.
_______________________________________________
Web-SIG mailing list
Web-SIG@python.org
Web SIG: http://www.python.org/sigs/web-sig
Unsubscribe:
http://mail.python.org/mailman/options/web-sig/archive%40mail-archive.com
