On Mon, Oct 25, 2010 at 13:30, Francesc Alted <fal...@pytables.org> 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 Pytables-users@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/pytables-users