On Wed, Sep 9, 2009 at 5:03 PM, Mel<mwil...@the-wire.com> wrote: > David Stanek wrote: >> On Wed, Sep 9, 2009 at 12:45 PM, Andrey Fedorov<anfedo...@gmail.com> >> wrote: > >>> I've written a function [1] called apply_some which takes a set of >>> keywords arguments, filters only those a function is expecting, and >>> calls the function with only those arguments. This is meant to >>> suppress TypeErrors - [ ... ] > >> What is your use-case for using this? It seems really odd to me. > > I may have run into one possible use. I have a program that uses DB-API 2.0 > to work with a database, sometimes SQLite3, sometimes PostgreSQL. Connect > parameters are built up in a dict from a combination of defaults, > environment values, and command-line arguments. This dictionary has to be > pruned down before calling connect, because sqlite3.connect doesn't take the > wide assortment of arguments that are needed for PostgreSQL. The existing > program does this "by hand", being programmed in advance to know which > parameters are acceptable to which database module. >
The way I would normally do it is to use the URI format and based on the scheme choose a handler. For example: mysql://u...@host:server/db, would translate to a mysql specific function that knows what to do. Adding support for new schemes does mean an additional function, but I like the control. And it's explicit. I worry about the magic of the OP's approach. In your example generate a dictionary in a generic way and apply it to a set of functions. What happens if in the future if connect_mysql adds adds a parameter with the same name as one in connect_postgres, but different semantics. Now the magic is broken and you have an ugly special case. -- David blog: http://www.traceback.org twitter: http://twitter.com/dstanek -- http://mail.python.org/mailman/listinfo/python-list