On Mon, Oct 25, 2010 at 13:30, Francesc Alted <[email protected]> wrote:
> Now that I think, I ended implementing this behaviour because I needed a
> way to pass a lot of parameters to the computational kernel. For
> passing such parameters, I implemented the next methods for `Expr`:
>
> * setInputsRange(start=None, stop=None, step=None)
> * setOutput(out, append_mode=False)
> * setOutputRange(start=None, stop=None, step=None)
>
> Do you think that it is better to be able to pass these params to
> `eval()` instead? Hmm, I'm not that sure...
Contrary to you, I wouldn't mind that solution, but I can understand
that you don't like it. Another option which would satisfy my needs
would be to have a "setUservars" method in addition to the others, so
that I could keep the same object to do my computation.
Another paradigm you *might* want to explore is a "generative"
approach (as is used for example for SQLAlchemy queries): each of
those methods return a new object, copying all aspects from the
expression except those changed by the "current" method. That way, you
could write:
e = Expr("a + 2 * b")
e_range = e.setInputRanges(10, 20)
e1 = e_range.setOutput(out1)
e2 = e_range.setOutput(out2)
I would find it nice but it is not important enough for me that I'd be
willing to write a patch for it, and this issue is totally orthogonal
to the uservars one.
--
Gaëtan de Menten
------------------------------------------------------------------------------
Nokia and AT&T present the 2010 Calling All Innovators-North America contest
Create new apps & games for the Nokia N8 for consumers in U.S. and Canada
$10 million total in prizes - $4M cash, 500 devices, nearly $6M in marketing
Develop with Nokia Qt SDK, Web Runtime, or Java and Publish to Ovi Store
http://p.sf.net/sfu/nokia-dev2dev
_______________________________________________
Pytables-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/pytables-users
