All
As per the recommendations, all arguments are now passed in the
initialization of the method. It has definitely made for a cleaner
interface.
Thanks a lot for the input.
Angadh
On Thursday, August 2, 2012 2:40:20 AM UTC-5, Joachim Durchholz wrote:
>
> 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 view this discussion on the web visit
https://groups.google.com/d/msg/sympy/-/gslRTTFNzCIJ.
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.
