Brock Pytlik wrote:
[email protected] wrote:
On Wed, Oct 21, 2009 at 10:47:17AM -0700, Danek Duvall wrote:
Brock Pytlik wrote:
I think we've had this conversation before, but I think having
functions
which accept types with materially different interfaces (ie, the code
basically has to do isinstance/issubclass), leads to code which is
harder
to maintain and use. (Maybe I've simply missed the right way to handle
this, but I'm pretty sure such a check will need to be made.) That
said,
I guess this is the "pythonic" way of doing things, so I'll switch
to it.
Thanks. I don't think the maintenance burden is high, and I really hate
having to pretend we're C and have a mass of slightly differently named
functions based on what kind of parameters we're passing in. If we had
language built-in support for function polymorphism based on argument
types, we'd just use that, but that's not possible to do in Python.
There are a number of kinds of function polymorhpism that aren't
supported in Python. I was under the impression that other languages
allowed functions with the same name to vary by number of arguments and
type. However, Python does have the *args, **kwargs syntax to function
calls. That might be useful in a case like this.
-j
I'm even more hesitant to use that approach since it suggests that
set_content could take both (or neither) actions and strings at the same
time. I like having mandatory arguments as I think it means we catch
errors sooner, but maybe I'm wrong about that.
I basically see three options:
1) keep things the way they are
2) keep the function arguments the same but do a issubclass/isinstance
check and use a different branch depending on the results
3) have the function take two optional arguments and iterate over both
I don't have strong feelings about the way to go here. So, if someone
feels strongly, please speak up. If not, I'll probably go with 2.
Another option:
4) have the function take two optional arguments and assert that *one*
of them is defined, but not both
--
Shawn Walker
_______________________________________________
pkg-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/pkg-discuss
