Am 02.08.2012 00:58, schrieb Aaron Meurer:
I think a more Pythonic way if you don't want to have a function call
that is ten lines long is to first build up the dictionary and then
just call func(**kwargs), where kwargs is the dictionary. So the
approach will look more like
opts = {}
opt['opt1'] = 1
opt['opt2'] = False
...
func(arg1, arg2, **opt)
As I said elsewhere, "more Pythonic" isn't a very helpful criterion.
Real questions, in ascending order of importance, are:
- What's easier to write?
- What's easier to read?
- What's easier to adapt to changing requirements?
- What's less prone to errors?
"More Pythonic" in itself doesn't help deciding what's better since it's
unclear which of these aspects it means. Mostly the "easier to read" one
since more idiomatic code is easier to read, but that's really not the
most important one. Plus, SymPy seems to be in somewhat widespread use,
to SymPy is in fact one of the projects that *define* what's "Pythonic" ;-)
Now... how do the alternatives look, and how do they fare wrt. to the
four questions above?
*Positional arguments*
func(arg1, arg2, opt1, null, opt3, ...)
-> Prone to errors. We all agree that's bad design.
*Keyword arguments*
func(arg1, arg2, opt1=..., opt3=..., ...)
-> Typos in the option names aren't detected at compile time, so there's
a slight problem in "easier to write" here.
*Dictionaries*
opts = {}
opts['opt1'] = ...
opts['opt3'] = ...
func(arg1, arg2, opts)
-> Better, but mistyped option names will go unnoticed unless every
opts-consuming function does a check whether it knows all names. I.e.
we're somewhat hampered on the accounts of "prone to errors" and "ease
of adaptation to changing requirements".
-> The nice thing is that it interoperates well with the keyword
arguments approach.
*DSL / Builder*
Builder(arg1, arg2)
.opt1(...)
.opt3(...)
. ...
.func()
-> Compared to the keyword argument approach, typos in the option names
are now caught by the runtime instead of via user code, so we get a
slight improvement in the "prone to errors" area.
-> Users can write a stdBuild(arg1,arg2) function that returns
Builder(arg1,arg2).opt1(...). That's an object with the standard
settings already predetermined, and remaining settings left as blanks to
fill in.
-> Remember that the Builder class members are essentially just a
dictionary. The final call could still be in kwargs form.
Now a small advantage on an important question can always be overridden
by a huge advantage on a less important questions.
And I'm a bit out of my league determining how small or large the
aspects outlined above are.
When I weigh the aspects I have seen, from my perspective, I'm seeing
kwargs and DSL both at the top (can't decide which one is first place),
with dictionaries considerably behind and positional arguments far behind.
YMMV :-)
Regards,
Jo
P.S.: Sorry for wall of text...
--
You received this message because you are subscribed to the Google Groups
"sympy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sympy?hl=en.
